From openssl-users at dukhovni.org  Mon Apr  1 04:13:11 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 1 Apr 2019 00:13:11 -0400
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
Message-ID: <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>

A resumed session holds not just the ticket, but also the server
certificate, so that one examine the certificate and its saved
verification status, ...  And of course you need not just the
ticket, but also the master key (in the session object).

> On Mar 31, 2019, at 3:56 PM, Jeremy Harris <jgh at wizmail.org> wrote:
> 
> Having to store an entire ASN.1-coded session in a DB, at
> some 1250 byte versus 160 for the ticket is suboptimal.
> 
> This is for client-side TLS1.2 resumption, when the clients
> are separate processes and time-separated.

OpenSSL promises more state at the end of session resumption, and
so the necessary state is carried along.  For an MTA the size of
saved sessions is not a substantial barrier.

-- 
	Viktor.


From miconda at gmail.com  Mon Apr  1 07:40:43 2019
From: miconda at gmail.com (Daniel-Constantin Mierla)
Date: Mon, 1 Apr 2019 09:40:43 +0200
Subject: libssl 1.1 blocking with multi-forking application
Message-ID: <e2d507c4-033b-cdcd-3aef-ee4eb2beb372@gmail.com>

Hello,

we have been used libssl 0.9.x/1.0.x with no issue for more than 15
years in a multi-forking application, respectively Kamailio SIP server.
The application is initializing in the main process (including loading
data from database like mysql or postgress) then creates a pool of
processes. We are setting our memory management functions as well as
locking functions for 0.9.x/1.0.x.

With the internal changes in the libssl 1.1, the locking functions
cannot be set any more. However, it appears that it ends up in a
deadlock, or at least long time blocking. I received several such
reports from different people running Debian stable. Few of them
switched back to compile against libssl 1.0.x and no such issue happened
again.

Has anyone else here experienced something similar?

For a better understanding of how we use libssl, here is what happens:

? 1) kamailio starts and sets the memory management functions for libssl
? 2) it loads data from backend/database into memory -- this can create
connections to database servers using external libs (e.g., mysql) that
may use libssl
? 3) once the initialization is done (connections to backends should be
also closed), it knows how many child processes will be forked and
creates a dedicated SSL_CTX for each of them
? 4) kamailio forks and each process is using its own SSL_CTX structure
for accepting or connecting over tls -- each child process will also
reconnect to backend, if it needs it for runtime
? 5) after a while, several processes try to acquire same mutex inside
libssl/libcrypto, but that seems to be already acquired -- I paste next
two partial backtraces from different processes taken when blocking
happen, the others are similar and the rest of processes are waiting for
traffic on the network, their backtrace don't show they do anything with
libssl at that moment -- see all at
https://sip.antisip.com/kamailio-trap-tcp-down.txt

Note that we do not create threads in our application, but we cannot
control if an used external library (e.g., mysql client) does it. Also,
the tls connection can be used by different child processes.

Digging a bit in the libssl code, my first thoughts of a possible issue
went to the type of locks created by libcrypto, because they are not
process shared. Normally, operations to read/write for a connections
should happen in one process, then when no traffic, the child process
can move to another connection and handle traffic on it and other
process can get to the previous connection once it has new traffic to
handle.

Anyone having hints about what can be wrong there? Is libssl 1.1
supposed to be initialized/used in a different way for a multi-forking
application with use of a tls connection between child processes?

Thanks,
Daniel

#0  0x00007ff8eedb7470 in futex_wait (private=<optimized out>, expected=18780, futex_word=0x7ff8de86130c) at ../sysdeps/unix/sysv/linux/futex-internal.h:61
        __ret = -512
        err = <optimized out>
#1  futex_wait_simple (private=<optimized out>, expected=18780, futex_word=0x7ff8de86130c) at ../sysdeps/nptl/futex-internal.h:135
No locals.
#2  __pthread_rwlock_wrlock_slow (rwlock=0x7ff8de861300) at pthread_rwlock_wrlock.c:67
        waitval = 18780
        result = 0
        futex_shared = <optimized out>
#3  0x00007ff8ef189ee9 in CRYPTO_THREAD_write_lock () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
#4  0x00007ff8ef158c08 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
#5  0x00007ff8ef4a3caf in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
No symbol table info available.
#6  0x00007ff8ef4994ff in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
No symbol table info available.
#7  0x00007ff8ef491f61 in SSL_do_handshake () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1


#0  0x00007ff8eedb7470 in futex_wait (private=<optimized out>, expected=918, futex_word=0x7ff8de86130c) at ../sysdeps/unix/sysv/linux/futex-internal.h:61
        __ret = -512
        err = <optimized out>
#1  futex_wait_simple (private=<optimized out>, expected=918, futex_word=0x7ff8de86130c) at ../sysdeps/nptl/futex-internal.h:135
No locals.
#2  __pthread_rwlock_wrlock_slow (rwlock=0x7ff8de861300) at pthread_rwlock_wrlock.c:67
        waitval = 918
        result = 0
        futex_shared = <optimized out>
#3  0x00007ff8ef189ee9 in CRYPTO_THREAD_write_lock () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
#4  0x00007ff8ef158756 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
#5  0x00007ff8ef4a7465 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
No symbol table info available.
#6  0x00007ff8ef4997ee in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
No symbol table info available.
#7  0x00007ff8ef491f61 in SSL_do_handshake () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1
No symbol table info available.

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

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

From steffenl.sw at gmail.com  Mon Apr  1 13:46:43 2019
From: steffenl.sw at gmail.com (Steffen)
Date: Mon, 1 Apr 2019 15:46:43 +0200
Subject: PKCS#7/CMS verify reports bad signature
Message-ID: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>

Hello,

I am struggling with using OpenSSL 1.1.1 to verify a PKCS #7/CMS structure.
Verification succeeds when I use OpenSSL 1.0.2, but 1.1.0 and 1.1.1 fails
with "bad signature". I initially had this problem when using the OpenSSL
library but I see that the problem also applies to the OpenSSL CLI.

I am at loss and need some help with this issue. Please see the commands I
used below. Thank you for any assistance you can provide!

Notes:

   - "-noverify" was used because the certificates expired.
   - Verification succeeds when specifying "-nosigs".
   - "openssl cms -verify [...]" behaves the same way.
   - Since the files I am working with (test.der and test-data.bin) are
   part of a private project, I am not ready to share these in public.
   - I do not know exactly how the message structure was created but I
   guess either with some OpenSSL 1.0.2, Java with or without BouncyCastle.

Commands used:

# Environment: macOS 10.14.3 / Homebrew

$ /usr/local/opt/openssl/bin/openssl version
OpenSSL 1.0.2r  26 Feb 2019

$ /usr/local/opt/openssl/bin/openssl smime -verify -inform der -in test.der
-content test-data.bin -noverify
Verification successful

$ /usr/local/opt/openssl\@1.1/bin/openssl version
OpenSSL 1.1.1b  26 Feb 2019

$ /usr/local/opt/openssl\@1.1/bin/openssl smime -verify -inform der -in
test.der -content test-data.bin -noverify
Verification failure
4563408320:error:04091068:rsa routines:int_rsa_verify:bad
signature:crypto/rsa/rsa_sign.c:220:
4563408320:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature
failure:crypto/pkcs7/pk7_doit.c:1037:
4563408320:error:21075069:PKCS7 routines:PKCS7_verify:signature
failure:crypto/pkcs7/pk7_smime.c:353:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190401/40cd95e1/attachment-0001.html>

From matt at openssl.org  Mon Apr  1 13:57:50 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 1 Apr 2019 14:57:50 +0100
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
Message-ID: <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>



On 01/04/2019 14:46, Steffen wrote:
> Hello,
> 
> I am struggling with using OpenSSL 1.1.1 to verify a PKCS #7/CMS structure.
> Verification succeeds when I use OpenSSL 1.0.2, but 1.1.0 and 1.1.1 fails with
> "bad signature". I initially had this problem when using the OpenSSL library but
> I see that the problem also applies to the OpenSSL CLI.

Could be this (from CHANGES):

  *) Fixed a text canonicalisation bug in CMS

     Where a CMS detached signature is used with text content the text goes
     through a canonicalisation process first prior to signing or verifying a
     signature. This process strips trailing space at the end of lines, converts
     line terminators to CRLF and removes additional trailing line terminators
     at the end of a file. A bug in the canonicalisation process meant that
     some characters, such as form-feed, were incorrectly treated as whitespace
     and removed. This is contrary to the specification (RFC5485). This fix
     could mean that detached text data signed with an earlier version of
     OpenSSL 1.1.0 may fail to verify using the fixed version, or text data
     signed with a fixed OpenSSL may fail to verify with an earlier version of
     OpenSSL 1.1.0. A workaround is to only verify the canonicalised text data
     and use the "-binary" flag (for the "cms" command line application) or set
     the SMIME_BINARY/PKCS7_BINARY/CMS_BINARY flags (if using CMS_verify()).
     [Matt Caswell]

Matt

> 
> I am at loss and need some help with this issue. Please see the commands I used
> below. Thank you for any assistance you can provide!
> 
> Notes:
> 
>   * "-noverify" was used because the certificates expired.
>   * Verification succeeds when specifying "-nosigs".
>   * "openssl cms -verify [...]" behaves the same way.
>   * Since the files I am working with (test.der and test-data.bin) are part of a
>     private project, I am not ready to share these in public.
>   * I do not know exactly how the message structure was created but I guess
>     either with some OpenSSL 1.0.2, Java with or without BouncyCastle.
> 
> Commands used:
> 
> # Environment: macOS 10.14.3 / Homebrew
> ?
> $ /usr/local/opt/openssl/bin/openssl version
> OpenSSL 1.0.2r ?26 Feb 2019
> ?
> $ /usr/local/opt/openssl/bin/openssl smime -verify -inform der -in test.der
> -content test-data.bin -noverify
> Verification successful
> ?
> $ /usr/local/opt/openssl\@1.1/bin/openssl version
> OpenSSL 1.1.1b ?26 Feb 2019
> ?
> $ /usr/local/opt/openssl\@1.1/bin/openssl smime -verify -inform der -in test.der
> -content test-data.bin -noverify
> Verification failure
> 4563408320:error:04091068:rsa routines:int_rsa_verify:bad
> signature:crypto/rsa/rsa_sign.c:220:
> 4563408320:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature
> failure:crypto/pkcs7/pk7_doit.c:1037:
> 4563408320:error:21075069:PKCS7 routines:PKCS7_verify:signature
> failure:crypto/pkcs7/pk7_smime.c:353:

From jgh at wizmail.org  Mon Apr  1 14:01:36 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 1 Apr 2019 15:01:36 +0100
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
Message-ID: <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>

Thanks for the explanation.  Next, serialise/deseralise
of the session is failing.  Test code:

  {
  SSL_SESSION * ss = SSL_get_session(ssl);

  uschar * sess_asn1;
  int len;

  len = i2d_SSL_SESSION(ss, &sess_asn1);

{
SSL_SESSION * ss = NULL;
if (!(d2i_SSL_SESSION(&ss, CUSS &sess_asn1, (long)len)))
  {
  DEBUG(D_tls)
    {
    ERR_error_string_n(ERR_get_error(),
      ssl_errstring, sizeof(ssl_errstring));
    debug_printf("decoding session: %s\n", ssl_errstring);
    }
  }
}


gets me:
"decoding session: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag"

-- 
Cheers,
  Jeremy

From steffenl.sw at gmail.com  Mon Apr  1 14:33:26 2019
From: steffenl.sw at gmail.com (Steffen)
Date: Mon, 1 Apr 2019 16:33:26 +0200
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
Message-ID: <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>

Hello Matt,

Thank you for your reply!

I am not quite sure if I should do something more but specifying "-binary"
alone does not seem to help:

# 1.0.2r
$ /usr/local/opt/openssl/bin/openssl cms -verify -inform der -in test.der
-content test-data.bin -noverify -binary > /dev/null
Verification successful

# 1.1.1b
$ /usr/local/opt/openssl\@1.1/bin/openssl cms -verify -inform der -in
test.der -content test-data.bin -noverify -binary > /dev/null
Verification failure
4465374656:error:04091068:rsa routines:int_rsa_verify:bad
signature:crypto/rsa/rsa_sign.c:220:
4465374656:error:2E09809E:CMS routines:CMS_SignerInfo_verify:verification
failure:crypto/cms/cms_sd.c:741:

Other ideas are much appreciated!

On Mon, Apr 1, 2019 at 3:58 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 01/04/2019 14:46, Steffen wrote:
> > Hello,
> >
> > I am struggling with using OpenSSL 1.1.1 to verify a PKCS #7/CMS
> structure.
> > Verification succeeds when I use OpenSSL 1.0.2, but 1.1.0 and 1.1.1
> fails with
> > "bad signature". I initially had this problem when using the OpenSSL
> library but
> > I see that the problem also applies to the OpenSSL CLI.
>
> Could be this (from CHANGES):
>
>   *) Fixed a text canonicalisation bug in CMS
>
>      Where a CMS detached signature is used with text content the text goes
>      through a canonicalisation process first prior to signing or
> verifying a
>      signature. This process strips trailing space at the end of lines,
> converts
>      line terminators to CRLF and removes additional trailing line
> terminators
>      at the end of a file. A bug in the canonicalisation process meant that
>      some characters, such as form-feed, were incorrectly treated as
> whitespace
>      and removed. This is contrary to the specification (RFC5485). This fix
>      could mean that detached text data signed with an earlier version of
>      OpenSSL 1.1.0 may fail to verify using the fixed version, or text data
>      signed with a fixed OpenSSL may fail to verify with an earlier
> version of
>      OpenSSL 1.1.0. A workaround is to only verify the canonicalised text
> data
>      and use the "-binary" flag (for the "cms" command line application)
> or set
>      the SMIME_BINARY/PKCS7_BINARY/CMS_BINARY flags (if using
> CMS_verify()).
>      [Matt Caswell]
>
> Matt
>
> >
> > I am at loss and need some help with this issue. Please see the commands
> I used
> > below. Thank you for any assistance you can provide!
> >
> > Notes:
> >
> >   * "-noverify" was used because the certificates expired.
> >   * Verification succeeds when specifying "-nosigs".
> >   * "openssl cms -verify [...]" behaves the same way.
> >   * Since the files I am working with (test.der and test-data.bin) are
> part of a
> >     private project, I am not ready to share these in public.
> >   * I do not know exactly how the message structure was created but I
> guess
> >     either with some OpenSSL 1.0.2, Java with or without BouncyCastle.
> >
> > Commands used:
> >
> > # Environment: macOS 10.14.3 / Homebrew
> >
> > $ /usr/local/opt/openssl/bin/openssl version
> > OpenSSL 1.0.2r  26 Feb 2019
> >
> > $ /usr/local/opt/openssl/bin/openssl smime -verify -inform der -in
> test.der
> > -content test-data.bin -noverify
> > Verification successful
> >
> > $ /usr/local/opt/openssl\@1.1/bin/openssl version
> > OpenSSL 1.1.1b  26 Feb 2019
> >
> > $ /usr/local/opt/openssl\@1.1/bin/openssl smime -verify -inform der -in
> test.der
> > -content test-data.bin -noverify
> > Verification failure
> > 4563408320:error:04091068:rsa routines:int_rsa_verify:bad
> > signature:crypto/rsa/rsa_sign.c:220:
> > 4563408320:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature
> > failure:crypto/pkcs7/pk7_doit.c:1037:
> > 4563408320:error:21075069:PKCS7 routines:PKCS7_verify:signature
> > failure:crypto/pkcs7/pk7_smime.c:353:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190401/2878c6ff/attachment.html>

From steffenl.sw at gmail.com  Mon Apr  1 21:23:21 2019
From: steffenl.sw at gmail.com (Steffen)
Date: Mon, 1 Apr 2019 23:23:21 +0200
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
Message-ID: <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>

Hello,

I believe that I have narrowed the problem down to one specific version of
OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not.

I have currently only verified this using PKCS7_verify and CMS_verify since
I have no CLI at hand for these versions.

The changelog for 1.1.0c describes the following change for CMS:

  *) CMS Null dereference

     Applications parsing invalid CMS structures can crash with a NULL pointer
     dereference. This is caused by a bug in the handling of the ASN.1 CHOICE
     type in OpenSSL 1.1.0 which can result in a NULL value being passed to the
     structure callback if an attempt is made to free certain invalid encodings.
     Only CHOICE structures using a callback which do not handle NULL value are
     affected.

     This issue was reported to OpenSSL by Tyler Nighswander of ForAllSecure.
     (CVE-2016-7053)
     [Stephen Henson]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190401/e8f4fd79/attachment-0001.html>

From openssl-users at dukhovni.org  Mon Apr  1 23:31:57 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 1 Apr 2019 19:31:57 -0400
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
Message-ID: <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>



> On Apr 1, 2019, at 10:01 AM, Jeremy Harris <jgh at wizmail.org> wrote:
> 
> Thanks for the explanation.  Next, serialise/deseralise
> of the session is failing.  Test code:
> 
>  {
>  SSL_SESSION * ss = SSL_get_session(ssl);
> 
>  uschar * sess_asn1;
>  int len;
> 
>  len = i2d_SSL_SESSION(ss, &sess_asn1);

This is incorrect use of the api.  You need to provide a NULL
buffer, obtain the length, then call again, after allocating
a buffer of the requisite size.  Here's an example from the
DANE code in Postfix (likely similar code already in Exim):

        len = i2d_X509(cert, NULL);
        buf2 = buf = (unsigned char *) mymalloc(len);
        i2d_X509(cert, &buf2);

Note that i2d updates its second argument to point to the end of
the buffer just written, which supports append operations, but
means you also need a pointer to the original buffer, hence
the "buf2 = buf = ...".  The serialized data is sandwiched
between "buf" (start) and "buf2" (end).

-- 
-- 
	Viktor.


From matt at openssl.org  Tue Apr  2 08:44:30 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 2 Apr 2019 09:44:30 +0100
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
 <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
Message-ID: <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>



On 01/04/2019 22:23, Steffen wrote:
> Hello,
> 
> I believe that I have narrowed the problem down to one specific version of
> OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not.

Using the cert/data files you provided me off-list (thanks), I was able to
confirm the above and narrow it down further to the following commit:

commit b71079a375116a8a52ed493afcd8f69cb08c195a
Author: David Benjamin <davidben at google.com>
Date:   Sat Aug 20 13:35:17 2016 -0400

    Implement RSASSA-PKCS1-v1_5 as specified.

    RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode
    the DigestInfo struct and then compare the result against the public key
    operation result. This implies that one and only one encoding is legal.

    OpenSSL instead parses with crypto/asn1, then checks that the encoding
    round-trips, and allows some variations for the parameter. Sufficient
    laxness in this area can allow signature forgeries, as described in
    https://www.imperialviolet.org/2014/09/26/pkcs1.html

    Although there aren't known attacks against OpenSSL's current scheme,
    this change makes OpenSSL implement the algorithm as specified. This
    avoids the uncertainty and, more importantly, helps grow a healthy
    ecosystem. Laxness beyond the spec, particularly in implementations
    which enjoy wide use, risks harm to the ecosystem for all. A signature
    producer which only tests against OpenSSL may not notice bugs and
    accidentally become widely deployed. Thus implementations have a
    responsibility to honor the specification as tightly as is practical.

    In some cases, the damage is permanent and the spec deviation and
    security risk becomes a tax all implementors must forever pay, but not
    here. Both BoringSSL and Go successfully implemented and deployed
    RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
    this change should be compatible enough to pin down in future OpenSSL
    releases.

    See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

    As a bonus, by not having to deal with sign/verify differences, this
    version is also somewhat clearer. It also more consistently enforces
    digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath
    wasn't quite doing this right.

    Reviewed-by: Kurt Roeckx <kurt at roeckx.be>
    Reviewed-by: Rich Salz <rsalz at openssl.org>

    GH: #1474
    (cherry picked from commit 608a026494c1e7a14f6d6cfcc5e4994fe2728836)

Implemented via this pull request:
https://github.com/openssl/openssl/pull/1474

So, based on the above description, it appears that older versions of OpenSSL
were unduly lenient in tolerating incorrectly formatted signatures. As a
security hardening measure that tolerance was removed. If you want to know more
then David Benjamin may be able to expand.

Matt


From jgh at wizmail.org  Tue Apr  2 09:54:43 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Tue, 2 Apr 2019 10:54:43 +0100
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
Message-ID: <7d9d4889-bf46-2413-0086-be9c4f6b9ab1@wizmail.org>

On 02/04/2019 00:31, Viktor Dukhovni wrote:
>>  len = i2d_SSL_SESSION(ss, &sess_asn1);
> 
> This is incorrect use of the api.  You need to provide a NULL
> buffer, obtain the length, then call again, after allocating
> a buffer of the requisite size.

Thanks (again).  Perhaps a note of this in the manpage
would be good?  And any other i2d_* pages?
-- 
Cheers,
  Jeremy


From steffenl.sw at gmail.com  Tue Apr  2 10:11:53 2019
From: steffenl.sw at gmail.com (Steffen)
Date: Tue, 2 Apr 2019 12:11:53 +0200
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
 <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
 <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
Message-ID: <CAMwAdU2BpEv7z4EtaUCF7oVvpfTV6RfAEng5UrEs1_=yhcrNFQ@mail.gmail.com>

Hello Matt,

Thank you for looking into this!

So it seems like I have to figure out why the signatures are incorrectly
formatted and then fix it at every source if possible, or convert the
structures somehow if it can be done correctly. The only immediate solution
I can see is to downgrade to OpenSSL 1.0.2r or 1.1.0b until I figure out
what to do about it. These seem like pretty bad ideas right now but I am
blocked otherwise.

I do not have any further questions because I guess this is a dead end if I
cannot fix this correctly, but please feel free to share any thoughts.
CC-ing David Benjamin as well.

Thank you!

Regards,
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190402/3fca94ae/attachment.html>

From jb-openssl at wisemo.com  Tue Apr  2 10:42:18 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 2 Apr 2019 12:42:18 +0200
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
 <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
 <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
Message-ID: <8118444e-1764-3068-844e-17ddd9ee214b@wisemo.com>

On 02/04/2019 10:44, Matt Caswell wrote:
>
> On 01/04/2019 22:23, Steffen wrote:
>> Hello,
>>
>> I believe that I have narrowed the problem down to one specific version of
>> OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not.
> Using the cert/data files you provided me off-list (thanks), I was able to
> confirm the above and narrow it down further to the following commit:
>
> commit b71079a375116a8a52ed493afcd8f69cb08c195a
> Author: David Benjamin <davidben at google.com>
> Date:   Sat Aug 20 13:35:17 2016 -0400
>
>      Implement RSASSA-PKCS1-v1_5 as specified.
>
>      RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode
>      the DigestInfo struct and then compare the result against the public key
>      operation result. This implies that one and only one encoding is legal.
>
>      OpenSSL instead parses with crypto/asn1, then checks that the encoding
>      round-trips, and allows some variations for the parameter. Sufficient
>      laxness in this area can allow signature forgeries, as described in
>      https://www.imperialviolet.org/2014/09/26/pkcs1.html
>
>      Although there aren't known attacks against OpenSSL's current scheme,
>      this change makes OpenSSL implement the algorithm as specified. This
>      avoids the uncertainty and, more importantly, helps grow a healthy
>      ecosystem. Laxness beyond the spec, particularly in implementations
>      which enjoy wide use, risks harm to the ecosystem for all. A signature
>      producer which only tests against OpenSSL may not notice bugs and
>      accidentally become widely deployed. Thus implementations have a
>      responsibility to honor the specification as tightly as is practical.
>
>      In some cases, the damage is permanent and the spec deviation and
>      security risk becomes a tax all implementors must forever pay, but not
>      here. Both BoringSSL and Go successfully implemented and deployed
>      RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
>      this change should be compatible enough to pin down in future OpenSSL
>      releases.
>
>      See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
>
>      As a bonus, by not having to deal with sign/verify differences, this
>      version is also somewhat clearer. It also more consistently enforces
>      digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath
>      wasn't quite doing this right.
>
>      Reviewed-by: Kurt Roeckx <kurt at roeckx.be>
>      Reviewed-by: Rich Salz <rsalz at openssl.org>
>
>      GH: #1474
>      (cherry picked from commit 608a026494c1e7a14f6d6cfcc5e4994fe2728836)
>
> Implemented via this pull request:
> https://github.com/openssl/openssl/pull/1474
>
> So, based on the above description, it appears that older versions of OpenSSL
> were unduly lenient in tolerating incorrectly formatted signatures. As a
> security hardening measure that tolerance was removed. If you want to know more
> then David Benjamin may be able to expand.
Please note that CMS countersignatures made using a specific Symantec 
server
(specifically to timestamp the original CMS signature with a long-valid 
signed
timestamp) happened to use a different PKCS#1.x signature format until very
recently.? This signature had a different but similar input to the raw RSA
algorithm, and was only ever done with Sha1RSA.

According to my notes, this format was only ever used with sha1RSA and 
md5RSA,
In this format, the DER encoding and hash OID is skipped, and instead 
the raw
20 or 16 byte hash is placed where the DER encoded tuple should be.? The
surrounding padding was apparently the same is in PKCS#1.5 signatures, 
as was
the OIDs identifying this algorithm.

I don't know if an older PKCS#1 document (before 1.5) actually specified 
this
format, only that is was present in the wild.



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 tsrini.alr at gmail.com  Tue Apr  2 13:02:29 2019
From: tsrini.alr at gmail.com (Srinivasan T)
Date: Tue, 2 Apr 2019 18:32:29 +0530
Subject: Upgrading OpenSSL in CentOS
Message-ID: <CABqMVLe7MK2OggadYi0kaDMOJ=UO15qfcpYm8Y0+=oPkAZwwvA@mail.gmail.com>

Hi Team,

Recently we have upgraded to CentOS 7.6.1810 and the OpenSSL comes along
with CentOS 7.6 is openssl-1.0.2k-16.el7_6.1.x86_64. We understand there
are no updates available / backported in CentOS 7.6 mirrors beyond
openssl-1.0.2k.

Can we upgrade OpenSSL to 1.0.2r (for CVE fixes)? Is it right way to get it
upgraded ourself though there are no updates from CentOS.

Regards,
Srini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190402/4cfb756d/attachment-0001.html>

From mcr at sandelman.ca  Tue Apr  2 13:51:05 2019
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 02 Apr 2019 09:51:05 -0400
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
 <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
 <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
Message-ID: <25072.1554213065@localhost>


Matt Caswell <matt at openssl.org> wrote:
    > Using the cert/data files you provided me off-list (thanks), I was able to
    > confirm the above and narrow it down further to the following commit:

What had produced the signatures?

    > In some cases, the damage is permanent and the spec deviation and
    > security risk becomes a tax all implementors must forever pay, but not
    > here. Both BoringSSL and Go successfully implemented and deployed
    > RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
    > this change should be compatible enough to pin down in future OpenSSL
    > releases.

    > So, based on the above description, it appears that older versions of OpenSSL
    > were unduly lenient in tolerating incorrectly formatted signatures. As a
    > security hardening measure that tolerance was removed. If you want to know more
    > then David Benjamin may be able to expand.

Did openssl ever produce these wrong signatures?



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190402/5ff88668/attachment.sig>

From hkario at redhat.com  Tue Apr  2 14:08:57 2019
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 02 Apr 2019 16:08:57 +0200
Subject: Upgrading OpenSSL in CentOS
In-Reply-To: <CABqMVLe7MK2OggadYi0kaDMOJ=UO15qfcpYm8Y0+=oPkAZwwvA@mail.gmail.com>
References: <CABqMVLe7MK2OggadYi0kaDMOJ=UO15qfcpYm8Y0+=oPkAZwwvA@mail.gmail.com>
Message-ID: <2051065.Yc7JxqAnEk@pintsize.usersys.redhat.com>

On Tuesday, 2 April 2019 15:02:29 CEST Srinivasan T wrote:
> Hi Team,
> 
> Recently we have upgraded to CentOS 7.6.1810 and the OpenSSL comes along
> with CentOS 7.6 is openssl-1.0.2k-16.el7_6.1.x86_64. We understand there
> are no updates available / backported in CentOS 7.6 mirrors beyond
> openssl-1.0.2k.
> 
> Can we upgrade OpenSSL to 1.0.2r (for CVE fixes)? Is it right way to get it
> upgraded ourself though there are no updates from CentOS.

the version of the package represents only the oldest code that's equal with 
the upstream releases; see RPM changelog for the CVE fixes

also:
https://access.redhat.com/security/updates/backporting

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190402/3e87dcd3/attachment.sig>

From openssl-users at dukhovni.org  Tue Apr  2 14:26:46 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 2 Apr 2019 10:26:46 -0400
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <7d9d4889-bf46-2413-0086-be9c4f6b9ab1@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <7d9d4889-bf46-2413-0086-be9c4f6b9ab1@wizmail.org>
Message-ID: <20190402142646.GO1347@straasha.imrryr.org>

On Tue, Apr 02, 2019 at 10:54:43AM +0100, Jeremy Harris wrote:

> > This is incorrect use of the api.  You need to provide a NULL
> > buffer, obtain the length, then call again, after allocating
> > a buffer of the requisite size.
> 
> Thanks (again).  Perhaps a note of this in the manpage
> would be good?  And any other i2d_* pages?

The 1.1.0 (and later) documentation reads:

    https://www.openssl.org/docs/man1.1.0/man3/d2i_SSL_SESSION.html

    These functions decode and encode an SSL_SESSION object. For
    encoding details see d2i_X509(3).

which leads to:

    https://www.openssl.org/docs/man1.1.0/man3/d2i_X509.html

    i2d_TYPE() encodes the structure pointed to by a into DER format.
    If ppout is not NULL, it writes the DER encoded data to the
    buffer at *ppout, and increments it to point after the data
    just written. If the return value is negative an error occurred,
    otherwise it returns the length of the encoded data.

    If *ppout is NULL memory will be allocated for a buffer and the
    encoded data written to it. In this case *ppout is not incremented
    and it points to the start of the data just written.

The "1.0.2" version (after running the word-wrapped HTML code
example through "indent") reads:

    https://www.openssl.org/docs/man1.0.2/man3/d2i_SSL_SESSION.html

    When using i2d_SSL_SESSION(), the memory location pointed to
    by pp must be large enough to hold the binary representation
    of the session. There is no known limit on the size of the
    created ASN1 representation, so the necessary amount of space
    should be obtained by first calling i2d_SSL_SESSION() with
    pp=NULL, and obtain the size needed, then allocate the memory
    and call i2d_SSL_SESSION() again. Note that this will advance
    the value contained in *pp so it is necessary to save a copy
    of the original allocation. For example:

	int		i, j;
	char	       *p, *temp;

	i = i2d_SSL_SESSION(sess, NULL);
	p = temp = malloc(i);
	j = i2d_SSL_SESSION(sess, &temp);
	assert(i == j);
	assert(p + i == temp);

-- 
	Viktor.

From openssl-users at dukhovni.org  Tue Apr  2 16:03:58 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 2 Apr 2019 12:03:58 -0400
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
Message-ID: <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>

> On Apr 2, 2019, at 11:17 AM, Jeremy Harris <jgh at wizmail.org> wrote:
> 
> If I understand right from rfc5077 the next record from the server after
> the server-hello should have been an empty session_ticket, if it was
> going to accept the resumed session.  But it goes on to a full handshake
> instead.
> 
> Is there any way of finding out what it didn't like?

Does the server have a temporally stable ticket decryption key?
Is this Exim?  Is the server's SSL_CTX persistent and shared
across multiple connections?  IIRC Exim has a completely fresh
SSL stack initialized after fork for every client...

-- 
	Viktor.


From steffenl.sw at gmail.com  Tue Apr  2 16:34:00 2019
From: steffenl.sw at gmail.com (Steffen)
Date: Tue, 2 Apr 2019 18:34:00 +0200
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <25072.1554213065@localhost>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
 <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
 <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
 <25072.1554213065@localhost>
Message-ID: <CAMwAdU1+xOsELuB8Zub31Tgkf21qtkbUDg7tTTttVFfi5a=t4A@mail.gmail.com>

Hello,

> What had produced the signatures?

I received word from my end that the signatures may have been produced by
OpenSSL 1.0.2 (no idea which letter release) in the Cygwin environment but
I cannot confirm this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190402/f55941c7/attachment.html>

From Michael.Wojcik at microfocus.com  Tue Apr  2 16:53:14 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 2 Apr 2019 16:53:14 +0000
Subject: libssl 1.1 blocking with multi-forking application
In-Reply-To: <e2d507c4-033b-cdcd-3aef-ee4eb2beb372@gmail.com>
References: <e2d507c4-033b-cdcd-3aef-ee4eb2beb372@gmail.com>
Message-ID: <BYAPR18MB291811C9AF9BCA0AAF1AF48EF9560@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Daniel-Constantin Mierla
> Sent: Monday, April 01, 2019 03:41
>
>  4) kamailio forks and each process is using its own SSL_CTX structure for accepting or
> connecting over tls -- each child process will also reconnect to backend, if it needs it for
> runtime

Unfortunately for your purposes, OpenSSL does not guarantee correct operation when called from the child side of a fork (prior to exec). See:

https://wiki.openssl.org/index.php/Libcrypto_API#Fork_Safety

That said, using OpenSSL in a non-exec'd child process is common enough that the wiki also has a page on reseeding the PRNG after a fork - no longer relevant with 1.1, with the PRNG rewrite, but it suggests that the issue was relatively common.

Based on the evidence (which isn't much), it appears at least one of the locks (implemented as pthread mutexes on Linux) was locked when you forked. Since libcrypto and libssl aren't built with symbols, we can't guess which lock.

I suggest you build OpenSSL for debugging so you can get some useful information at the point of failure, then try to trace it back to confirm what was locked after the fork (put a breakpoint on the child side of the fork, then inspect the mutex object at that point). Then you can try to figure out why it was locked when you forked.

OpenSSL 1.1.1b doesn't seem to provide a way to reinitialize the mutexes programmatically after a fork.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From matt at openssl.org  Wed Apr  3 07:59:01 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 3 Apr 2019 08:59:01 +0100
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <CAMwAdU1+xOsELuB8Zub31Tgkf21qtkbUDg7tTTttVFfi5a=t4A@mail.gmail.com>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
 <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
 <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
 <25072.1554213065@localhost>
 <CAMwAdU1+xOsELuB8Zub31Tgkf21qtkbUDg7tTTttVFfi5a=t4A@mail.gmail.com>
Message-ID: <20d2a0b1-d062-81f9-f6a7-5e8e1b047539@openssl.org>



On 02/04/2019 17:34, Steffen wrote:
> Hello,
> 
>> What had produced the signatures?
> 
> I received word from my end that the signatures may have been produced by
> OpenSSL 1.0.2 (no idea which letter release) in the Cygwin environment but I
> cannot confirm this.
> 

If that's the case, I'd really like to know what specific version and how the
signatures were generated (although it seems a little surprising if 1.0.2 is
creating these incorrect signatures that no-one else has encountered this, since
the commit in question went in over 2.5 years ago).

Matt

From steffenl.sw at gmail.com  Wed Apr  3 08:47:44 2019
From: steffenl.sw at gmail.com (Steffen)
Date: Wed, 3 Apr 2019 10:47:44 +0200
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <20d2a0b1-d062-81f9-f6a7-5e8e1b047539@openssl.org>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
 <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
 <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
 <25072.1554213065@localhost>
 <CAMwAdU1+xOsELuB8Zub31Tgkf21qtkbUDg7tTTttVFfi5a=t4A@mail.gmail.com>
 <20d2a0b1-d062-81f9-f6a7-5e8e1b047539@openssl.org>
Message-ID: <CAMwAdU3a0XNeofeNX_JK8cTEownmgnv7Y5qaByWeNsAsjmYNeA@mail.gmail.com>

Hello,

I think the person I spoke with might have thought about another set of
signatures for an in-house identity provider. If that is the case then
those signatures were probably generated by OpenSSL 1.0.2 and are OK. I
heard from another person today that the bad files were produced by the
other primary identity provider we use, so we must support the existing
format. Now I really do not see any other solution but to either downgrade
or fork OpenSSL.

On Wed, Apr 3, 2019 at 9:59 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 02/04/2019 17:34, Steffen wrote:
> > Hello,
> >
> >> What had produced the signatures?
> >
> > I received word from my end that the signatures may have been produced by
> > OpenSSL 1.0.2 (no idea which letter release) in the Cygwin environment
> but I
> > cannot confirm this.
> >
>
> If that's the case, I'd really like to know what specific version and how
> the
> signatures were generated (although it seems a little surprising if 1.0.2
> is
> creating these incorrect signatures that no-one else has encountered this,
> since
> the commit in question went in over 2.5 years ago).
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190403/d6a17041/attachment.html>

From jgh at wizmail.org  Wed Apr  3 20:16:10 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Wed, 3 Apr 2019 21:16:10 +0100
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
Message-ID: <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>

On 02/04/2019 17:03, Viktor Dukhovni wrote:
> Does the server have a temporally stable ticket decryption key?
> Is this Exim?  Is the server's SSL_CTX persistent and shared
> across multiple connections?

Ah, right.  Unlike GnuTLS, the STEK is tied to the SSL_CTX and,
as you say, Exim initialises that fresh per connection.
Rearchitecting that is more effort than it's worth spending
on TLS 1.2, I think.
-- 
Thanks,
  Jeremy

From jb-openssl at wisemo.com  Wed Apr  3 21:13:59 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 3 Apr 2019 23:13:59 +0200
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
Message-ID: <f608d874-fb13-1d61-e976-46d4e122dc71@wisemo.com>

On 03/04/2019 22:16, Jeremy Harris wrote:
> On 02/04/2019 17:03, Viktor Dukhovni wrote:
>> Does the server have a temporally stable ticket decryption key?
>> Is this Exim?  Is the server's SSL_CTX persistent and shared
>> across multiple connections?
> Ah, right.  Unlike GnuTLS, the STEK is tied to the SSL_CTX and,
> as you say, Exim initialises that fresh per connection.
> Rearchitecting that is more effort than it's worth spending
> on TLS 1.2, I think.

As an Exim user (can already be seen in my mail headers), I always
wondered about the weird way that Exim (according to the docs/spec)
tries to reinit TLS for each message on a connection.

It seemed very much contrary to protocol, unlike the simple
approach of running TLS in one process, piping the plaintext
(E)SMTP stream to/from a succession of message processing processes,
which can be reforked without breaking the stream and without
ability to steal TLS keys through any security vulnerabilities.

When a non-TLS ESMTP process sends or receives the STARTTLS
command, it can exit with a magic exit code causing the non-TLS
parent process to fork a TLS process and spawn fresh ESMTP
processes.? Alternatively non-TLS ESMTP processes could run
through a dummy TLS process that can be instructed out-of-band
to start TLS negotiation at the right time.

This (could provide better batching of connection overhead than
session tickets, as it saves even the TCP SYN packets while
lowering load on the remote servers and all intervening
stateful firewalls.

Enjoy

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


From openssl-users at dukhovni.org  Wed Apr  3 22:09:59 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 3 Apr 2019 18:09:59 -0400
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
Message-ID: <E2CC41D6-0DBC-4F99-B66A-A4FC2EEF4505@dukhovni.org>



> On Apr 3, 2019, at 4:16 PM, Jeremy Harris <jgh at wizmail.org> wrote:
> 
>> Does the server have a temporally stable ticket decryption key?
>> Is this Exim?  Is the server's SSL_CTX persistent and shared
>> across multiple connections?
> 
> Ah, right.  Unlike GnuTLS, the STEK is tied to the SSL_CTX and,
> as you say, Exim initialises that fresh per connection.
> Rearchitecting that is more effort than it's worth spending
> on TLS 1.2, I think.

Well, the *default* STEK is in the SSL_CTX, but that is not a
requirement, and you should use the default STEK, since it is
not automatically rolled over.

Postfix instantiates the ticket management callbacks, which
are registered per-ctx, but the associated key material is
then wherever the application (e.g. Postfix) decides to keep
them.

So you, and should, manage STEKs separately from the SSL_CTX,
and as appropriate tie the same keys to any appropriate SSL_CTX
by instantiating the appropriate callbacks.

The one thing to be mindful of is that if you have different
TLS policies across different SSL_CTX objects, they should
probably not share keys, otherwise it *may* be possible for
sessions to be established against a weak policy and then
inappropriately resumed against a service with a stronger
policy.  The solution is to assign different session id
contexts to SSL_CTX's that should not allow cross-resumption.

The SSL_CTX_set_session_id_context(3) allows you to specify
such a session id context.  I just looked at the documentation
of SSL_CTX_set_session_id_context(3), and is rather poor.
You just need to know that the context is binary data up
a maximum length you must not exceed, and the signature
of the function.  The description is largely wrong. :-(

-- 
	Viktor.


From rama.krushna7 at gmail.com  Thu Apr  4 07:32:34 2019
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Thu, 4 Apr 2019 13:02:34 +0530
Subject: Reg Speed test and Assembly code usage
In-Reply-To: <CAHgr=k+3hropSNOdgmwH-9o60hShEAMTiB9-g-k1UWBg8PiAOQ@mail.gmail.com>
References: <mailman.14348.1553682979.21411.openssl-users@openssl.org>
 <CAHgr=k+3hropSNOdgmwH-9o60hShEAMTiB9-g-k1UWBg8PiAOQ@mail.gmail.com>
Message-ID: <CAHgr=kLFs0G4q-EM4qnuZGkkTwqRMD+A5m6q4Ct1HDwMixOjkw@mail.gmail.com>

Hi,

Could anyone please help me get the following information.

-- How to verify that the openssl  is using the assembly code ( when asm is
enabled) instead of the c code for the algorithms ?
-- I m observing a small degradation (2 % for 16 byte size) for des-ede3 on
openssl1.1.1 for Solaris. This might not be suggested to use the algorithm,
but for learning purpose is there something that I can do to see if this
can be improved.

Thanks and Regards,
Ram Krushna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190404/d9bb2995/attachment.html>

From enrico.scholz at sigma-chemnitz.de  Thu Apr  4 11:26:01 2019
From: enrico.scholz at sigma-chemnitz.de (Enrico Scholz)
Date: Thu, 04 Apr 2019 13:26:01 +0200
Subject: Setter methods for X509_REQ signature attributes
Message-ID: <lyy34qvwom.fsf@ensc-virt.intern.sigma-chemnitz.de>

Hello,

I want to use OpenSSL to create an X509 request where the signature has
been calculated by an external device (ATMEL ATECC508A).  With OpenSSL
1.0 I used

	X509_REQ *req;

	req = X509_REQ_new();

	algor = X509_ALGOR_new();
	algor->algorithm = OBJ_nid2obj(NID_ecdsa_with_SHA256);
	X509_ALGOR_free(req->sig_alg);
	req->sig_alg = algor;

	ASN1_BIT_STRING_set(req->signature, asn1sig, asn1len);
	req->signature->flags &= ~(ASN1_STRING_FLAG_BITS_LEFT | 0x07);
	req->signature->flags |= ASN1_STRING_FLAG_BITS_LEFT;


How can I port this code to OpenSSL 1.1?  There do not seem to exist
setter methods for 'sig_alg' or 'signature'.

I could use X509_REQ_get0_signature(), cast away the 'const' from the
returned pointers and modify them.  But this would be hacky and not
portable.

What is the recommended way to create an X509 REQ with OpenSSL 1.1 when
all the crypto has been done in the outside and I need only the ASN.1
structure?

Would it be possible to add setter methods for 'sig_alg' and 'signature'?


Thanks
Enrico

From mann.patidar at gmail.com  Thu Apr  4 14:57:59 2019
From: mann.patidar at gmail.com (Manish Patidar)
Date: Thu, 4 Apr 2019 20:27:59 +0530
Subject: Standard used in EVP_SealInit/EVP_OpenInit
Message-ID: <CAN6ajHJcasptse7uZjARfttFHk=0djJ35ZdOYZk=bcq80vRL=A@mail.gmail.com>

Hi

is there any standard/rfc for EVP_SealInit .

Regards
Manish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190404/618fa86c/attachment.html>

From openssl-users at dukhovni.org  Thu Apr  4 15:16:23 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 4 Apr 2019 11:16:23 -0400
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <E2CC41D6-0DBC-4F99-B66A-A4FC2EEF4505@dukhovni.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
 <E2CC41D6-0DBC-4F99-B66A-A4FC2EEF4505@dukhovni.org>
Message-ID: <20190404151623.GT1347@straasha.imrryr.org>

On Wed, Apr 03, 2019 at 06:09:59PM -0400, Viktor Dukhovni wrote:

> > Ah, right.  Unlike GnuTLS, the STEK is tied to the SSL_CTX and,
> > as you say, Exim initialises that fresh per connection.
> > Rearchitecting that is more effort than it's worth spending
> > on TLS 1.2, I think.
> 
> Well, the *default* STEK is in the SSL_CTX, but that is not a
> requirement, and you should use the default STEK, since it is
> not automatically rolled over.

[ Correction: ... should *not* use the default STEK, ... ]

For an example ticket callback implementation, see:

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L294-L337

On line 315:

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L315

either the matching keyset (current active for creating a new ticket,
either active or previous when decrypting an existing ticket) is
selected, and the requested HMAC_CTX and EVP_CIPHER_CTX structures
are initialized appropriately.  Keyset, because the HMAC and AES
keys are separate.  The ticket encryption algorithm chosen by Postfix
defaults to aes-256-cbc.  OpenSSL does not support AEAD for ticket
encryption.

-- 
	Viktor.

From dclarke at blastwave.org  Thu Apr  4 15:43:34 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Thu, 4 Apr 2019 11:43:34 -0400
Subject: Reg Speed test and Assembly code usage
In-Reply-To: <CAHgr=kLFs0G4q-EM4qnuZGkkTwqRMD+A5m6q4Ct1HDwMixOjkw@mail.gmail.com>
References: <mailman.14348.1553682979.21411.openssl-users@openssl.org>
 <CAHgr=k+3hropSNOdgmwH-9o60hShEAMTiB9-g-k1UWBg8PiAOQ@mail.gmail.com>
 <CAHgr=kLFs0G4q-EM4qnuZGkkTwqRMD+A5m6q4Ct1HDwMixOjkw@mail.gmail.com>
Message-ID: <25a524c5-8815-31ed-e78f-31cf4d66012a@blastwave.org>

On 4/4/19 3:32 AM, ramakrushna mishra wrote:
> Hi,
> 
> Could anyone please help me get the following information.?
> 
> -- How to verify that the openssl? is using the assembly code ( when asm
> is enabled) instead of the c code for the algorithms ??
> -- I m observing a small degradation (2 % for 16 byte size) for des-ede3
> on openssl1.1.1 for Solaris. This might not be suggested to use the
> algorithm, but for learning purpose is there something that I can do to
> see if this can be improved.?

You will see plenty of lost performance on Solaris. It is a very very
slow old platform.  Also very little anyone can do to fix that.

For example here is a 15 year old Apple PowerMac :


hydra$ uname -a
FreeBSD hydra 13.0-CURRENT FreeBSD 13.0-CURRENT r344744 GENERIC  powerpc
hydra$ /usr/bin/openssl version
OpenSSL 1.1.1b-freebsd  26 Feb 2019
hydra$ /usr/bin/openssl speed rsa4096
Doing 4096 bits private rsa's for 10s: 83 4096 bits private RSA's in 10.02s
Doing 4096 bits public rsa's for 10s: 5808 4096 bits public RSA's in 10.00s
OpenSSL 1.1.1b-freebsd  26 Feb 2019
built on: reproducible build, date unspecified
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc
                  sign    verify    sign/s verify/s
rsa 4096 bits 0.120764s 0.001722s      8.3    580.8
hydra$



Here is a fairly new Oracle M3000 server :


s10sparc$ uname -a
SunOS corv 5.10 Generic_150400-64 sun4u sparc SUNW,SPARC-Enterprise

s10sparc$ /bin/sparcv9/openssl version
OpenSSL 1.0.2p  14 Aug 2018
s10sparc$ /bin/sparcv9/openssl speed rsa4096
Doing 4096 bit private rsa's for 10s: 86 4096 bit private RSA's in 10.06s
Doing 4096 bit public rsa's for 10s: 5896 4096 bit public RSA's in 10.00s
OpenSSL 1.0.2p  14 Aug 2018
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,int) des(ptr,risc1,16,int)
aes(partial) blowfish(ptr)
compiler: information not available
                  sign    verify    sign/s verify/s
rsa 4096 bits 0.116977s 0.001696s      8.5    589.6
s10sparc$


An expensive Oracle Netra T4-1 is not much better.


s10sparc$ /usr/local/bin/openssl version
OpenSSL 1.1.1b  26 Feb 2019
s10sparc$ /usr/local/bin/openssl speed rsa4096
Doing 4096 bits private rsa's for 10s: 78 4096 bits private RSA's in 10.08s
Doing 4096 bits public rsa's for 10s: 8229 4096 bits public RSA's in 10.00s
OpenSSL 1.1.1b  26 Feb 2019
built on: Tue Mar 26 06:51:39 2019 UTC
options:bn(64,32) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: /opt/developerstudio12.6/bin/cc -KPIC -m64 -Xa -g
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff
-xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc
-ftrap=%none -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc
-xdebugformat=dwarf -xstrconst -m64 -xarch=sparc -g -Xa -errfmt=error
-erroff=%none -errshort=full -xstrconst -xildoff -xmemalign=8s
-xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none
-xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf -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 -D_REENTRANT
-DNDEBUG -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS
-D_LARGEFILE64_SOURCE -D_TS_ERRNO
                  sign    verify    sign/s verify/s
rsa 4096 bits 0.129231s 0.001215s      7.7    822.9
s10sparc$


Also a dirt cheap machine built from spare parts :


fbsd_amd64$
fbsd_amd64$ uname -a
FreeBSD vesta 13.0-CURRENT FreeBSD 13.0-CURRENT r345173 GENERIC  amd64
fbsd_amd64$ /usr/bin/openssl version
OpenSSL 1.1.1b-freebsd  26 Feb 2019
fbsd_amd64$ /usr/bin/openssl speed rsa4096
Doing 4096 bits private rsa's for 10s: 638 4096 bits private RSA's in 10.07s
Doing 4096 bits public rsa's for 10s: 43106 4096 bits public RSA's in 10.03s
OpenSSL 1.1.1b-freebsd  26 Feb 2019
built on: reproducible build, date unspecified
options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
                  sign    verify    sign/s verify/s
rsa 4096 bits 0.015784s 0.000233s     63.4   4297.2
fbsd_amd64$


Don't go looking for performance on Solaris anymore.  It isn't there.


Dennis

From Michal.Trojnara at stunnel.org  Thu Apr  4 20:43:36 2019
From: Michal.Trojnara at stunnel.org (Michal Trojnara)
Date: Thu, 4 Apr 2019 22:43:36 +0200
Subject: stunnel 5.51 released
Message-ID: <ffde2d5f-8e24-ae47-6204-0ffc9c92f057@stunnel.org>

Dear Users,

I have released version 5.51 of stunnel.

Version 5.51, 2019.04.04, urgency: MEDIUM
* New features
? - Hexadecimal PSK keys are automatically converted to binary.
? - Session ticket support (requires OpenSSL 1.1.1 or later).
??? "connect" address persistence is currently unsupported
??? with session tickets.
? - SMTP HELO before authentication (thx to Jacopo Giudici).
? - New "curves" option to control the list of elliptic
??? curves in OpenSSL 1.1.0 and later.
? - New "ciphersuites" option to control the list of
??? permitted TLS 1.3 ciphersuites.
? - Include file name and line number in OpenSSL errors.
? - Compatibility with the current OpenSSL 3.0.0-dev branch.
? - Better performance with SSL_set_read_ahead()/SSL_pending().
* Bugfixes
? - Fixed PSKsecrets as a global option (thx to Teodor Robas).
? - Fixed a memory allocation bug (thx to matanfih).

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

SHA-256 hashes:
77437cdd1aef1a621824bb3607e966534642fe90c69f4d2279a9da9fa36c3253?
stunnel-5.51.tar.gz
a0e26fde3ba09d6545cfbb44cab06ebd4ddf9c4b536e7d8eb76615ab54b2339c?
stunnel-5.51-win64-installer.exe
ee90bef40cb47617fe7372707dba119f5176cb0fd9eb1bc00cdd1e2c370041db?
stunnel-5.51-android.zip

Best regards,
??? Mike


From openssl-users at dukhovni.org  Fri Apr  5 04:55:02 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 5 Apr 2019 00:55:02 -0400
Subject: Setter methods for X509_REQ signature attributes
In-Reply-To: <lyy34qvwom.fsf@ensc-virt.intern.sigma-chemnitz.de>
References: <lyy34qvwom.fsf@ensc-virt.intern.sigma-chemnitz.de>
Message-ID: <20190405045502.GV1347@straasha.imrryr.org>

On Thu, Apr 04, 2019 at 01:26:01PM +0200, Enrico Scholz via openssl-users wrote:

> What is the recommended way to create an X509 REQ with OpenSSL 1.1 when
> all the crypto has been done in the outside and I need only the ASN.1
> structure?

See also the related:

	https://github.com/openssl/openssl/issues/8553
	https://github.com/openssl/openssl/issues/8514
	http://openssl.6102.n7.nabble.com/i2d-X509-REQ-gt-d2i-X509-REQ-asn1-encoding-routines-c2i-ASN1-OBJECT-invalid-object-encoding-a-object7-td76251.html

> Would it be possible to add setter methods for 'sig_alg' and 'signature'?

New setter methods are probably needed.  For now all you can do is
obtain the DER encoding of the X509_REQ_INFO, and creat from it the
DER encoding of the enclosing X509_REQ, by prepending a sequence
tag and length, and appending the signature OID, any parameters and
signature.  You can then, if desired, recover an X509_REQ object
via d2i_X509_REQ.

-- 
	Viktor.

From steffenl.sw at gmail.com  Fri Apr  5 21:31:58 2019
From: steffenl.sw at gmail.com (Steffen)
Date: Fri, 5 Apr 2019 23:31:58 +0200
Subject: PKCS#7/CMS verify reports bad signature
In-Reply-To: <CAMwAdU3a0XNeofeNX_JK8cTEownmgnv7Y5qaByWeNsAsjmYNeA@mail.gmail.com>
References: <CAMwAdU3hWAgqn9KdCcVDTF1iG6bh_S4tWEhCchJ=w+c=EB6E5A@mail.gmail.com>
 <d11f8e7b-a052-3065-ac81-9ba69ce23e86@openssl.org>
 <CAMwAdU2q1t8+wTntYLFERMuXSWQumur6PgjzEoajsQ9dtXOTLg@mail.gmail.com>
 <CAMwAdU0GHtKFcO7=w9hsOHqz=dmtXcF0z5mpZfc=8TyiO-y9Uw@mail.gmail.com>
 <9cf49c7f-af14-63c0-3e12-e5a5b0e72cc7@openssl.org>
 <25072.1554213065@localhost>
 <CAMwAdU1+xOsELuB8Zub31Tgkf21qtkbUDg7tTTttVFfi5a=t4A@mail.gmail.com>
 <20d2a0b1-d062-81f9-f6a7-5e8e1b047539@openssl.org>
 <CAMwAdU3a0XNeofeNX_JK8cTEownmgnv7Y5qaByWeNsAsjmYNeA@mail.gmail.com>
Message-ID: <CAMwAdU31TxLJHdbXjwKvoOswSY27J7T0=98r+GhyXCuBCPVm6w@mail.gmail.com>

Hello,

I have a small update in order to close this issue.

The identity provider that produced the invalid signatures have fixed their
signatures so that we can verify them using the latest LTS version of
OpenSSL. We use Bouncy Castle in some products and it does not catch the
invalid signatures either, or at least not the way we use it.

Anyway, this is a satisfactory outcome.

Thank you for the help, everyone!

Regards,
Steffen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190405/340a30c1/attachment.html>

From Chethan.Kumar at toshiba-tsip.com  Mon Apr  8 07:26:02 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Mon, 8 Apr 2019 07:26:02 +0000
Subject: migration from openssl 1.0.2n to 1.1.1
Message-ID: <447C096A3E2889439233CDD6DAB29F95AB750347@TOSBLRMBX03.TOSHIBA-TSIP.COM>

Dear all,

We did openssl version upgrade from 1.0.2n to 1.1.1. While compiling some package dependent on openssl, getting errors related to M_ASN1_ D2I AND I2D functions.
Digging deeper got to know that, in latest openssl asn1_mac.h header is deprecated.
Can someone please help me out in knowing what are changes to be done to make it work.?

We use following fucntions.
M_ASN1_I2D_len(a->issuer,i2d_X509_NAME);
M_ASN1_I2D_vars(a);
M_ASN1_I2D_len(a->subject,i2d_X509_NAME);
M_ASN1_I2D_seq_total();
M_ASN1_I2D_put(a->issuer,i2d_X509_NAME);
M_ASN1_I2D_put(a->subject,i2d_X509_NAME);
M_ASN1_I2D_finish();
M_ASN1_D2I_vars(a, pkcs7_issuer_and_subject *,
M_ASN1_D2I_Init();
M_ASN1_D2I_start_sequence();
M_ASN1_D2I_get(ret->issuer,d2i_X509_NAME);
M_ASN1_D2I_get(ret->subject,d2i_X509_NAME);
M_ASN1_D2I_Finish(a,pkcs7_issuer_and_subject_free, 99);
M_ASN1_New_Malloc(ret,pkcs7_issuer_and_subject);
M_ASN1_New(ret->issuer,X509_NAME_new);
M_ASN1_New(ret->subject,X509_NAME_new);
M_ASN1_New_Error(199);
M_ASN1_INTEGER_free(a->subject);

Thanking you,

With Regards,
Chethan Kumar

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190408/e917b81d/attachment-0001.html>

From jgh at wizmail.org  Mon Apr  8 08:27:07 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 8 Apr 2019 09:27:07 +0100
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <f608d874-fb13-1d61-e976-46d4e122dc71@wisemo.com>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
 <f608d874-fb13-1d61-e976-46d4e122dc71@wisemo.com>
Message-ID: <32f0b025-7c9e-29ec-285d-14a2ef54a429@wizmail.org>

On 03/04/2019 22:13, Jakob Bohm via openssl-users wrote:
> As an Exim user (can already be seen in my mail headers), I always
> wondered about the weird way that Exim (according to the docs/spec)
> tries to reinit TLS for each message on a connection.
> 
> It seemed very much contrary to protocol, unlike the simple
> approach of running TLS in one process, piping the plaintext
> (E)SMTP stream to/from a succession of message processing processes,
> which can be reforked without breaking the stream and without
> ability to steal TLS keys through any security vulnerabilities.

http://exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECTmulmessam

"for sending using TLS Exim starts an additional proxy process for
handling the encryption, piping the unencrypted data stream from and to
the delivery processes"

-- 
Cheers,
  Jeremy


From jernej+s-ossl at eternallybored.org  Mon Apr  8 08:22:46 2019
From: jernej+s-ossl at eternallybored.org (=?utf-8?Q?Jernej_Simon=C4=8Di=C4=8D?=)
Date: Mon, 8 Apr 2019 10:22:46 +0200
Subject: openssl.cnf required in 1.1.1b?
Message-ID: <1098760676.20190408102246@eternallybored.org>

I provide Windows binaries for wget, which I link statically, to make
wget.exe completely self-contained, and I use OpenSSL as the crypto
backend. This worked fine for years, but when I updated OpenSSL to
1.1.1b for the latest wget release, wget is now failing on some
systems with "Disabling SSL due to encountered errors.", which
apparently happens because the OpenSSL library needs to have a
configuration file now.

Is there any way to make OpenSSL 1.1.1b work without needing a
configuration file?

I configure OpenSSL with the following (I cross-compile wget from
Linux):

./Configure --cross-compile-prefix=x86_64-w64-mingw32- mingw64 no-shared zlib --prefix=/win32dev/misc/wget/out64 -L/win32dev/misc/wget/out64/lib -I/win32dev/misc/wget/out64/include -static

-- 
< Jernej Simon?i? ><><><><><><><><><><><>< https://eternallybored.org/ >

           Because 10 billion years' time is so fragile, so ephemeral...
it arouses such a bittersweet, almost heartbreaking fondness.


From matt at openssl.org  Mon Apr  8 13:42:15 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 8 Apr 2019 14:42:15 +0100
Subject: migration from openssl 1.0.2n to 1.1.1
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95AB750347@TOSBLRMBX03.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95AB750347@TOSBLRMBX03.TOSHIBA-TSIP.COM>
Message-ID: <335ea759-423b-6416-7722-0b34815bb544@openssl.org>



On 08/04/2019 08:26, Chethan Kumar wrote:
> Dear all,
> 
> ?
> 
> We did openssl version upgrade from 1.0.2n to 1.1.1. While compiling some
> package dependent on openssl, getting errors related to M_ASN1_ D2I AND I2D
> functions.
> 
> Digging deeper got to know that, in latest openssl asn1_mac.h header is deprecated.
> 
> Can someone please help me out in knowing what are changes to be done to make it
> work.?

It looks like you are using the very old ASN1 macros. These were replaced with
the current ASN1 code in 2002 - and then removed completely in 1.1.0.

Are you reading/writing custom ASN.1 structures? If so then you'll need to
update to use the new code. To see some examples take a look at the many ASN.1
structures defined in x509v3.h with matching "DECLARE_ASN1_FUNCTIONS" macro
calls to declare the i2d/d2i function to write/read them. Internally to OpenSSL
there are matching IMPLEMENT_ASN1_FUNCTIONS calls to provide the implementations
for these.

For example see this definition of an ASN.1 structure in the OpenSSL code:

https://github.com/openssl/openssl/blob/e9cfa192019574a75fbeca4811c10635a9049381/crypto/x509/x_x509a.c#L26-L34


The IMPLEMENT_ASN1_FUNCTIONS macro shown there results in the functions
described on this page being available:

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


Hope that helps,

Matt

From giovanni.fontana72 at gmail.com  Mon Apr  8 15:48:56 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Mon, 8 Apr 2019 17:48:56 +0200
Subject: new algorithms
Message-ID: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>

Hello everybody,

my name is Giovanni Fontana. I made a new symmetric crypto algorithm (let?s
call it *algo1*) and a new asymmetric crypto algorithm (let?s call it
*algo2*).

I use algo2 for key exchange and with that I can create a session key to
cipher and decipher with algo1, so Alice and Bob can communicate each other
in secure way.

I wish to import those algorithms inside OpenSSL in order to use some
features of this suite (i.e. creation of x509 certificate with algo1 and
algo2, and/or TLS and SSL connection always with algo1 and algo2).
My first tries were not successful.
Could you please tell me each step I have to do in order to achieve my
targets? Or share with me some Internet links where those steps are already
defined?

Below some info that may help you in answer me:
- The version of OpenSSL I?m playing with is 1.1.1b
- The OS is Linux Ubuntu 14.04
- Of course my algorithms are written in C.

Further question (probably to ask elsewhere inside OpenSSL organisation):
If in the next future with my algorithms I can have some business, which
kind of license I need to have with OpenSSL then?

Thank in advance
Kind regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190408/d18ee919/attachment.html>

From dclarke at blastwave.org  Mon Apr  8 16:06:11 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Mon, 8 Apr 2019 12:06:11 -0400
Subject: new algorithms
In-Reply-To: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
Message-ID: <8c6aca47-edca-eb08-1ecd-a0efd7e4e04e@blastwave.org>

On 4/8/19 11:48 AM, Giovanni Fontana wrote:
> Hello everybody,
> 
> my name is Giovanni Fontana. I made a new symmetric crypto algorithm
> (let?s call it?*algo1*) and a new asymmetric crypto algorithm (let?s
> call it?*algo2*).
> 
> I use algo2 for key exchange and with that I can create a session key to
> cipher and decipher with algo1, so Alice and Bob can communicate each
> other in secure way.

I think you would need to publish the algorithm at some point. Is there
a github link perhaps?

Dennis



From giovanni.fontana72 at gmail.com  Mon Apr  8 16:14:11 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Mon, 8 Apr 2019 18:14:11 +0200
Subject: new algorithms
In-Reply-To: <8c6aca47-edca-eb08-1ecd-a0efd7e4e04e@blastwave.org>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
 <8c6aca47-edca-eb08-1ecd-a0efd7e4e04e@blastwave.org>
Message-ID: <CAC-fp6NpeoATDWoe6fMBLvueOf=4qTFO8tGhqvuDVvb8qeJvpw@mail.gmail.com>

Hi Clarke,

Thanks for the email.
Sure, I want to publish the algorithm, but not yet... waiting for
establishing a company.
For similar reasons no github usage at moment.

Giovanni



Il giorno lun 8 apr 2019 alle 18:06 Dennis Clarke <dclarke at blastwave.org>
ha scritto:

> On 4/8/19 11:48 AM, Giovanni Fontana wrote:
> > Hello everybody,
> >
> > my name is Giovanni Fontana. I made a new symmetric crypto algorithm
> > (let?s call it *algo1*) and a new asymmetric crypto algorithm (let?s
> > call it *algo2*).
> >
> > I use algo2 for key exchange and with that I can create a session key to
> > cipher and decipher with algo1, so Alice and Bob can communicate each
> > other in secure way.
>
> I think you would need to publish the algorithm at some point. Is there
> a github link perhaps?
>
> Dennis
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190408/53ee27ea/attachment-0001.html>

From openssl-users at dukhovni.org  Mon Apr  8 16:38:58 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 8 Apr 2019 12:38:58 -0400
Subject: new algorithms
In-Reply-To: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
Message-ID: <20190408163858.GE87116@straasha.imrryr.org>

On Mon, Apr 08, 2019 at 05:48:56PM +0200, Giovanni Fontana wrote:

> my name is Giovanni Fontana. I made a new symmetric crypto algorithm (let?s
> call it *algo1*) and a new asymmetric crypto algorithm (let?s call it
> *algo2*).

Recent additions to OpenSSL include X25519, Ed25519 and ChaCha20.
If, for some reason, you believe that an important security problem
we're facing is an insufficient number of available algorithms, you
can study how these recent algorithms are integrated into OpenSSL
generally, X.509, CMS and TLS, and integrate your algorithms in a
similar manner.

You might also take a look at the OpenSSL master (3.0) development
branch, which introduces changes to the internal architecture that
are intended to better facilitate integration of external cryptographic
modules.

-- 
	Viktor.

From rsalz at akamai.com  Mon Apr  8 16:51:08 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 8 Apr 2019 16:51:08 +0000
Subject: new algorithms
In-Reply-To: <CAC-fp6NpeoATDWoe6fMBLvueOf=4qTFO8tGhqvuDVvb8qeJvpw@mail.gmail.com>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
 <8c6aca47-edca-eb08-1ecd-a0efd7e4e04e@blastwave.org>
 <CAC-fp6NpeoATDWoe6fMBLvueOf=4qTFO8tGhqvuDVvb8qeJvpw@mail.gmail.com>
Message-ID: <0631DC67-A64D-4123-B0C0-3EE3842C20B8@akamai.com>

  *   Sure, I want to publish the algorithm, but not yet... waiting for establishing a company.

This is a bit off-topic, but trying to make money from a cryptographic algorithm isn?t really done any more.  RSA was locked up by patents, and there were some elliptic curve patents that have since expired, but nobody really trusts private algorithms any more. There?s too much good stuff readily available.

To answer your other question: OpenSSL is covered by the Apache license and any contributions should also use the same license or they will not be accepted. And cryptography, in particular, has to be used by a recognized standards body.

Good luck.

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

From tniessen at tnie.de  Mon Apr  8 17:05:47 2019
From: tniessen at tnie.de (=?UTF-8?Q?Tobias_Nie=c3=9fen?=)
Date: Mon, 8 Apr 2019 19:05:47 +0200
Subject: new algorithms
In-Reply-To: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
Message-ID: <52dcc303-d98f-b439-441e-b0edc1ce1132@tnie.de>

> creation of x509 certificate with algo1 and algo2, and/or TLS and SSL 
> connection always with algo1 and algo2
As far as I know, you will need to have an OID assigned for each 
algorithm for x509 certificates. You can add those to OpenSSL manually, 
but you won't be able to communicate with any other software that does 
not implement them. (And as Rich said, there is little reason for people 
to trust and use non-standard algorithms.)

From 213tej at gmail.com  Mon Apr  8 17:22:57 2019
From: 213tej at gmail.com (Teja Prabhu)
Date: Mon, 8 Apr 2019 19:22:57 +0200
Subject: new algorithms
In-Reply-To: <52dcc303-d98f-b439-441e-b0edc1ce1132@tnie.de>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
 <52dcc303-d98f-b439-441e-b0edc1ce1132@tnie.de>
Message-ID: <CAOiJyu_q-i7LWVxgrSKzTfAWEv7x11F9EGn1tUhkT4DyR-98Bw@mail.gmail.com>

1. dasync_aes128_cbc_cipher (search for this in
https://github.com/openssl/openssl/blob/master/engines/e_dasync.c) ||
replace it with your symmetric cipher, and do the same for RSA.
2. setup a server and client and hard-code the symmetric & asymmetric
ciphers to your ciphers
3. your idea is simply not going to work. Like Tobias said, you have to add
them manually. I suggest you simply not use OpenSSL or any TLS library,
unless you have a lot of clout in the International Communication Union.

You can take Mega's approach and use javascript since every browser under
the sun has it (as an additional layer over TLS).

Teja Prabhu


On Mon, Apr 8, 2019 at 7:06 PM Tobias Nie?en <tniessen at tnie.de> wrote:

> > creation of x509 certificate with algo1 and algo2, and/or TLS and SSL
> > connection always with algo1 and algo2
> As far as I know, you will need to have an OID assigned for each
> algorithm for x509 certificates. You can add those to OpenSSL manually,
> but you won't be able to communicate with any other software that does
> not implement them. (And as Rich said, there is little reason for people
> to trust and use non-standard algorithms.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190408/381d348f/attachment.html>

From giovanni.fontana72 at gmail.com  Mon Apr  8 17:50:55 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Mon, 8 Apr 2019 19:50:55 +0200
Subject: new algorithms
In-Reply-To: <CAOiJyu_q-i7LWVxgrSKzTfAWEv7x11F9EGn1tUhkT4DyR-98Bw@mail.gmail.com>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
 <52dcc303-d98f-b439-441e-b0edc1ce1132@tnie.de>
 <CAOiJyu_q-i7LWVxgrSKzTfAWEv7x11F9EGn1tUhkT4DyR-98Bw@mail.gmail.com>
Message-ID: <CAC-fp6P9zEXRg9JQhQOzEdLoUvNzu5HWYRgoEtCp5UWNNwv-MA@mail.gmail.com>

Thank you every one for the answers and tips, really a great and active
group!

Thank you also to Teja and Tobias who has just wrote some suggestion on how
I can  have a technical shortcut to prove the functionality of my
algorithms in very limited environment.
What I asked is to move a first step (after the algorithms) to have a demo
before to setup a company.
For my limited knowledge I know  the algorithms need to be published and
security must be proved for some authorities. All I need to prove is the
algorithms works in the real world and openSSL is one of the most used tool
to do that, then the other steps

Thank you again for your answer, this is what I really need.

Giovanni



Il giorno lun 8 apr 2019 alle ore 19:23 Teja Prabhu <213tej at gmail.com> ha
scritto:

> 1. dasync_aes128_cbc_cipher (search for this in
> https://github.com/openssl/openssl/blob/master/engines/e_dasync.c) ||
> replace it with your symmetric cipher, and do the same for RSA.
> 2. setup a server and client and hard-code the symmetric & asymmetric
> ciphers to your ciphers
> 3. your idea is simply not going to work. Like Tobias said, you have to
> add them manually. I suggest you simply not use OpenSSL or any TLS library,
> unless you have a lot of clout in the International Communication Union.
>
> You can take Mega's approach and use javascript since every browser under
> the sun has it (as an additional layer over TLS).
>
> Teja Prabhu
>
>
> On Mon, Apr 8, 2019 at 7:06 PM Tobias Nie?en <tniessen at tnie.de> wrote:
>
>> > creation of x509 certificate with algo1 and algo2, and/or TLS and SSL
>> > connection always with algo1 and algo2
>> As far as I know, you will need to have an OID assigned for each
>> algorithm for x509 certificates. You can add those to OpenSSL manually,
>> but you won't be able to communicate with any other software that does
>> not implement them. (And as Rich said, there is little reason for people
>> to trust and use non-standard algorithms.)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190408/3a874db1/attachment-0001.html>

From mcr at sandelman.ca  Mon Apr  8 18:04:51 2019
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 08 Apr 2019 14:04:51 -0400
Subject: new algorithms
In-Reply-To: <52dcc303-d98f-b439-441e-b0edc1ce1132@tnie.de>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
 <52dcc303-d98f-b439-441e-b0edc1ce1132@tnie.de>
Message-ID: <32293.1554746691@localhost>


    >> creation of x509 certificate with algo1 and algo2, and/or TLS and SSL
    >> connection always with algo1 and algo2

Tobias Nie?en <tniessen at tnie.de> wrote:
    > As far as I know, you will need to have an OID assigned for each
    > algorithm for x509 certificates. You can add those to OpenSSL manually,
    > but you won't be able to communicate with any other software that does
    > not implement them. (And as Rich said, there is little reason for
    > people to trust and use non-standard algorithms.)

But, if your goal is private testing of your stuff, then any OID will do,
including one you allocate with a Private Enterprise Number, which you can get from
IANA by filling out a simple form.
You'll likely have to add the OIDs to the object.txt and run some scripts.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190408/94ea39f1/attachment.sig>

From Michal.Trojnara at stunnel.org  Mon Apr  8 19:38:02 2019
From: Michal.Trojnara at stunnel.org (Michal Trojnara)
Date: Mon, 8 Apr 2019 21:38:02 +0200
Subject: stunnel 5.52 released
Message-ID: <189f05cd-4f4b-1f1f-0a68-75496373702e@stunnel.org>

Dear Users,

I have released version 5.52 of stunnel.

Version 5.52, 2019.04.08, urgency: HIGH
* Bugfixes
? - Fixed a transfer() loop bug introduced in stunnel 5.51.

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

SHA-256 hashes:
00b973aa0d48b0707dd722c4e0a20b8378fc9b0ba301fdb785ffb75341024e21?
stunnel-5.52.tar.gz
c9224c35cdd3a6de8fab7c2844ca0c185ebcc96fd9183a05407e2ba77cadc7c6?
stunnel-5.52-win64-installer.exe
d4ff581e1547c2e194abd586e9542bfe20399c1287f970eaa5ba1824e4567453?
stunnel-5.52-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/20190408/173a1e22/attachment.sig>

From openssl at foocrypt.net  Tue Apr  9 00:57:47 2019
From: openssl at foocrypt.net (openssl at foocrypt.net)
Date: Tue, 9 Apr 2019 10:57:47 +1000
Subject: new algorithms
In-Reply-To: <CAC-fp6P9zEXRg9JQhQOzEdLoUvNzu5HWYRgoEtCp5UWNNwv-MA@mail.gmail.com>
References: <CAC-fp6N73dDHYh1JYDXqOK=OB7jKCinhOP=ZpwjoV7GuKfO6Xg@mail.gmail.com>
 <52dcc303-d98f-b439-441e-b0edc1ce1132@tnie.de>
 <CAOiJyu_q-i7LWVxgrSKzTfAWEv7x11F9EGn1tUhkT4DyR-98Bw@mail.gmail.com>
 <CAC-fp6P9zEXRg9JQhQOzEdLoUvNzu5HWYRgoEtCp5UWNNwv-MA@mail.gmail.com>
Message-ID: <5BF22013-27EE-4948-B2EC-4DA7674B8886@foocrypt.net>

HI Giovanni

Depending on the country you are located in, you may need to check the current status of your countries regulatory legislation regarding encryption technologies. 

Participating countries : https://www.wassenaar.org/participating-states/ <https://www.wassenaar.org/participating-states/> [ contacts ] & encryption is listed under Dual List Technologies : https://www.wassenaar.org/ <https://www.wassenaar.org/> is always a good place to start before drilling into your own locations specific regulations on encryption technologies.

All the best mate and hoping your invention prospers.


-- 

Regards,

Mark A. Lane   

? Mark A. Lane 1980 - 2019, All Rights Reserved.
? FooCrypt 1980 - 2019, All Rights Reserved.
? FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2019, All Rights Reserved.
? Cryptopocalypse 1980 - 2019, All Rights Reserved.

> On 9 Apr 2019, at 03:50, Giovanni Fontana <giovanni.fontana72 at gmail.com> wrote:
> 
> Thank you every one for the answers and tips, really a great and active group!
> 
> Thank you also to Teja and Tobias who has just wrote some suggestion on how I can  have a technical shortcut to prove the functionality of my algorithms in very limited environment.
> What I asked is to move a first step (after the algorithms) to have a demo before to setup a company. 
> For my limited knowledge I know  the algorithms need to be published and security must be proved for some authorities. All I need to prove is the algorithms works in the real world and openSSL is one of the most used tool to do that, then the other steps
> 
> Thank you again for your answer, this is what I really need.
> 
> Giovanni
> 
> 
> 
> Il giorno lun 8 apr 2019 alle ore 19:23 Teja Prabhu <213tej at gmail.com <mailto:213tej at gmail.com>> ha scritto:
> 1. dasync_aes128_cbc_cipher (search for this in https://github.com/openssl/openssl/blob/master/engines/e_dasync.c <https://github.com/openssl/openssl/blob/master/engines/e_dasync.c>) || replace it with your symmetric cipher, and do the same for RSA.
> 2. setup a server and client and hard-code the symmetric & asymmetric ciphers to your ciphers
> 3. your idea is simply not going to work. Like Tobias said, you have to add them manually. I suggest you simply not use OpenSSL or any TLS library, unless you have a lot of clout in the International Communication Union.
> 
> You can take Mega's approach and use javascript since every browser under the sun has it (as an additional layer over TLS).
> 
> Teja Prabhu
> 
> 
> On Mon, Apr 8, 2019 at 7:06 PM Tobias Nie?en <tniessen at tnie.de <mailto:tniessen at tnie.de>> wrote:
> > creation of x509 certificate with algo1 and algo2, and/or TLS and SSL 
> > connection always with algo1 and algo2
> As far as I know, you will need to have an OID assigned for each 
> algorithm for x509 certificates. You can add those to OpenSSL manually, 
> but you won't be able to communicate with any other software that does 
> not implement them. (And as Rich said, there is little reason for people 
> to trust and use non-standard algorithms.)

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

From Ashwinkumar.Metpalli at ncr.com  Tue Apr  9 16:05:04 2019
From: Ashwinkumar.Metpalli at ncr.com (Metpalli, Ashwinkumar)
Date: Tue, 9 Apr 2019 16:05:04 +0000
Subject: openssl-1.0.2r build fails on CE-X86 platform because of warning 
Message-ID: <BN8PR15MB26898FE573EC4396A4A2F8258A2D0@BN8PR15MB2689.namprd15.prod.outlook.com>

Dear OpenSSL Users,

This is my first interaction in this community.

While am trying to build the latest openssl-1.0.2r code on CE-X86 platform, it fails with the below error:

rsa_pk1.c
.\crypto\rsa\rsa_pk1.c(296) : warning C4761: integral size mismatch in argument
conversion supplied
.\crypto\rsa\rsa_pk1.c(296) : error C2220: warning treated as error - no object
file generated
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'

The below is the failing line (Line# 296) in rsa_pk1.c

               to[i] = constant_time_select_8(mask, from[i], to[i]); (Here the second parameter takes a unsigned char data type while the passed one is a const unsigned char )

Can I fix this just by type casting to unsigned char using a Perl patch? Is there a better way to fix this?

NOTE:


  1.  The above line doesn't exist in older code (1.0.2.q) and so no issues on older builds.
  2.  This new code builds fine on CE-Arm, CE-Shx, NT-VS10, NT-VS15 platforms however fails on CE-X86 platform alone and that too because of the warning.
  3.  We need to fix this warning and can't simply use something like Treat Warnings as Errors to No.
  4.  There seems to be similar other occurrences in other files which could also flag warning (For instance, s3_cbc.c).

Please advise.

Thank you,
Ashwin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190409/5b37e1f3/attachment-0001.html>

From jgh at wizmail.org  Tue Apr  9 22:52:59 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Tue, 9 Apr 2019 23:52:59 +0100
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <20190404151623.GT1347@straasha.imrryr.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
 <E2CC41D6-0DBC-4F99-B66A-A4FC2EEF4505@dukhovni.org>
 <20190404151623.GT1347@straasha.imrryr.org>
Message-ID: <16652dc5-6eef-f500-8cea-7ed029e5aba5@wizmail.org>

On 04/04/2019 16:16, Viktor Dukhovni wrote:
>> Well, the *default* STEK is in the SSL_CTX, but that is not a
>> requirement, and you should use the default STEK, since it is
>> not automatically rolled over.
> 
> [ Correction: ... should *not* use the default STEK, ... ]

So I have the server side mostly running, with rollover and
overlap... but in the client, when a session is succesfully
resumed but past the overlap period, and the server issues
a new ticket - the client SSL_SESSION is apparently unchanged
(at least, the ASN.1 dump of it is identical to that loaded
for resumption prior to handshake).

How is an overlapped key update supposed to be handled by
a client?
-- 
Thanks,
  Jeremy

From openssl-users at dukhovni.org  Wed Apr 10 00:25:25 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 9 Apr 2019 20:25:25 -0400
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <16652dc5-6eef-f500-8cea-7ed029e5aba5@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
 <E2CC41D6-0DBC-4F99-B66A-A4FC2EEF4505@dukhovni.org>
 <20190404151623.GT1347@straasha.imrryr.org>
 <16652dc5-6eef-f500-8cea-7ed029e5aba5@wizmail.org>
Message-ID: <20190410002525.GG87116@straasha.imrryr.org>

On Tue, Apr 09, 2019 at 11:52:59PM +0100, Jeremy Harris wrote:

> On 04/04/2019 16:16, Viktor Dukhovni wrote:
> >> Well, the *default* STEK is in the SSL_CTX, but that is not a
> >> requirement, and you should use the default STEK, since it is
> >> not automatically rolled over.
> > 
> > [ Correction: ... should *not* use the default STEK, ... ]
> 
> So I have the server side mostly running, with rollover and
> overlap... but in the client, when a session is succesfully
> resumed but past the overlap period, and the server issues
> a new ticket - the client SSL_SESSION is apparently unchanged
> (at least, the ASN.1 dump of it is identical to that loaded
> for resumption prior to handshake).
> 
> How is an overlapped key update supposed to be handled by
> a client?

With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object
associated with the connection object at the completion of each
handshake, will contain any fresh tickets issued by the server.

With TLS 1.3, the session tickets arrive post-handshake, and
so saving the session exactly when the handshake completes,
may not yet result in fresh tickets.

In Postfix, we implement the new session callbacks and then don't
care when the tickets arrive.  Whenever they do arrive the callback
happens, and the client session cache is updated at that point.

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L531-L556

The "external" (to OpenSSL) session cache implemented in Postfix,
has its own timeouts, and is periodically GC'd in the tlsmgr(8)
process discarding expired sessions.  There is one session per
lookup key, which captures not only the nexthop destination, endpoint
IP, peer HELO name (for split caches behind load-balancers), ...
but also a cryptographic hash of the TLS policy settings to avoid
accidental misuse.

For an in-memory cache, you could also bound the cache size, and
implement an LRU retired policy.  A priority search queue library
can provide the right abstraction.

-- 
	Viktor.

From valmikibow at gmail.com  Wed Apr 10 09:32:01 2019
From: valmikibow at gmail.com (valmiki)
Date: Wed, 10 Apr 2019 15:02:01 +0530
Subject: SSL write/read performance
In-Reply-To: <54920bf1-5506-fd10-46a1-4742ffd05809@gmail.com>
References: <54920bf1-5506-fd10-46a1-4742ffd05809@gmail.com>
Message-ID: <e109a252-d9f3-2453-5a07-8e40ea4ee301@gmail.com>

Hi All,

I'm trying to understand server and client code over tcp using openssl.

How does the flow work when we do SSL_write or SSL_read.

SSL_write -> send buffer to kernel crypto subsystem -> take encrypted buffer and send it over network socket.

Is the above understanding correct ?

If its correct we have following context switch from user to kernel space and vice versa

-> open ssl libary to kernel crypto subsystem

-> kernel crypto subsystem to ssl library

-> ssl library to network subsystem

Does this mean for sending a buffer we need to three context switches from user to kernel and vice versa ?

Doesn't this effect performance ?

Please correct me if my understanding is wrong.

Regards,
valmiki







From matt at openssl.org  Wed Apr 10 09:49:17 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Apr 2019 10:49:17 +0100
Subject: SSL write/read performance
In-Reply-To: <e109a252-d9f3-2453-5a07-8e40ea4ee301@gmail.com>
References: <54920bf1-5506-fd10-46a1-4742ffd05809@gmail.com>
 <e109a252-d9f3-2453-5a07-8e40ea4ee301@gmail.com>
Message-ID: <6fa675e8-f380-0b82-12d0-62e2ebcc106e@openssl.org>



On 10/04/2019 10:32, valmiki wrote:
> Hi All,
> 
> I'm trying to understand server and client code over tcp using openssl.
> 
> How does the flow work when we do SSL_write or SSL_read.
> 
> SSL_write -> send buffer to kernel crypto subsystem -> take encrypted buffer and send it over network socket.
> 
> Is the above understanding correct ?

No, this isn't correct. All crypto is done in user space* using libcrypto.

Matt

* Actually there is a new option in master where the kernel does the TLS
encryption/decryption - but it is not on by default, and if used the kernel does
the IO too.


> 
> If its correct we have following context switch from user to kernel space and vice versa
> 
> -> open ssl libary to kernel crypto subsystem
> 
> -> kernel crypto subsystem to ssl library
> 
> -> ssl library to network subsystem
> 
> Does this mean for sending a buffer we need to three context switches from user to kernel and vice versa ?
> 
> Doesn't this effect performance ?
> 
> Please correct me if my understanding is wrong.
> 
> Regards,
> valmiki
> 
> 
> 
> 
> 
> 

From valmikibow at gmail.com  Wed Apr 10 10:03:49 2019
From: valmikibow at gmail.com (valmiki)
Date: Wed, 10 Apr 2019 15:33:49 +0530
Subject: SSL write/read performance
In-Reply-To: <6fa675e8-f380-0b82-12d0-62e2ebcc106e@openssl.org>
References: <54920bf1-5506-fd10-46a1-4742ffd05809@gmail.com>
 <e109a252-d9f3-2453-5a07-8e40ea4ee301@gmail.com>
 <6fa675e8-f380-0b82-12d0-62e2ebcc106e@openssl.org>
Message-ID: <1cd71483-575e-267e-4c81-3a9f2de0d307@gmail.com>


>> Hi All,
>>
>> I'm trying to understand server and client code over tcp using openssl.
>>
>> How does the flow work when we do SSL_write or SSL_read.
>>
>> SSL_write -> send buffer to kernel crypto subsystem -> take encrypted buffer and send it over network socket.
>>
>> Is the above understanding correct ?
> No, this isn't correct. All crypto is done in user space* using libcrypto.
>
> Matt
>
> * Actually there is a new option in master where the kernel does the TLS
> encryption/decryption - but it is not on by default, and if used the kernel does
> the IO too.
>
> Thanks Matt.
> So only one context switch happens, which is sending buffer to networking 
> socket ?
>
> Regards,
> valimki
>> If its correct we have following context switch from user to kernel space and vice versa
>>
>> -> open ssl libary to kernel crypto subsystem
>>
>> -> kernel crypto subsystem to ssl library
>>
>> -> ssl library to network subsystem
>>
>> Does this mean for sending a buffer we need to three context switches from user to kernel and vice versa ?
>>
>> Doesn't this effect performance ?
>>
>> Please correct me if my understanding is wrong.
>>
>> Regards,
>> valmiki
>>
>>
>>
>>
>>
>>

From jgh at wizmail.org  Wed Apr 10 10:05:21 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Wed, 10 Apr 2019 11:05:21 +0100
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <20190410002525.GG87116@straasha.imrryr.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
 <E2CC41D6-0DBC-4F99-B66A-A4FC2EEF4505@dukhovni.org>
 <20190404151623.GT1347@straasha.imrryr.org>
 <16652dc5-6eef-f500-8cea-7ed029e5aba5@wizmail.org>
 <20190410002525.GG87116@straasha.imrryr.org>
Message-ID: <29fdb4c5-c855-ad73-f04e-30a01886f33f@wizmail.org>

On 10/04/2019 01:25, Viktor Dukhovni wrote:
> With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object
> associated with the connection object at the completion of each
> handshake, will contain any fresh tickets issued by the server.

That does not match my observation.
-- 
Cheers,
  Jeremy


From matt at openssl.org  Wed Apr 10 10:10:20 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Apr 2019 11:10:20 +0100
Subject: SSL write/read performance
In-Reply-To: <1cd71483-575e-267e-4c81-3a9f2de0d307@gmail.com>
References: <54920bf1-5506-fd10-46a1-4742ffd05809@gmail.com>
 <e109a252-d9f3-2453-5a07-8e40ea4ee301@gmail.com>
 <6fa675e8-f380-0b82-12d0-62e2ebcc106e@openssl.org>
 <1cd71483-575e-267e-4c81-3a9f2de0d307@gmail.com>
Message-ID: <71270f96-89b3-87da-a7d0-5064ccfbe43c@openssl.org>



On 10/04/2019 11:03, valmiki wrote:
> 
>>> Hi All,
>>>
>>> I'm trying to understand server and client code over tcp using openssl.
>>>
>>> How does the flow work when we do SSL_write or SSL_read.
>>>
>>> SSL_write -> send buffer to kernel crypto subsystem -> take encrypted buffer and send it over network socket.
>>>
>>> Is the above understanding correct ?
>> No, this isn't correct. All crypto is done in user space* using libcrypto.
>>
>> Matt
>>
>> * Actually there is a new option in master where the kernel does the TLS
>> encryption/decryption - but it is not on by default, and if used the kernel does
>> the IO too.
>>
>> Thanks Matt.
>> So only one context switch happens, which is sending buffer to networking 
>> socket ?

Correct.

Matt


From hkario at redhat.com  Wed Apr 10 10:15:31 2019
From: hkario at redhat.com (Hubert Kario)
Date: Wed, 10 Apr 2019 12:15:31 +0200
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <29fdb4c5-c855-ad73-f04e-30a01886f33f@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <20190410002525.GG87116@straasha.imrryr.org>
 <29fdb4c5-c855-ad73-f04e-30a01886f33f@wizmail.org>
Message-ID: <17096189.qQDxDkI9gr@pintsize.usersys.redhat.com>

On Wednesday, 10 April 2019 12:05:21 CEST Jeremy Harris wrote:
> On 10/04/2019 01:25, Viktor Dukhovni wrote:
> > With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object
> > associated with the connection object at the completion of each
> > handshake, will contain any fresh tickets issued by the server.
> 
> That does not match my observation.

that assumes that the server sends tickets in the first place... but the point 
stands, the TLS 1.2 server cannot provide a session ticket to the client after 
the handshake finished (client received server's Finished message), same for 
even older protocols

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190410/78e3e5d7/attachment.sig>

From jgh at wizmail.org  Wed Apr 10 10:21:08 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Wed, 10 Apr 2019 11:21:08 +0100
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <17096189.qQDxDkI9gr@pintsize.usersys.redhat.com>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <20190410002525.GG87116@straasha.imrryr.org>
 <29fdb4c5-c855-ad73-f04e-30a01886f33f@wizmail.org>
 <17096189.qQDxDkI9gr@pintsize.usersys.redhat.com>
Message-ID: <b31d8f98-ec07-adeb-1771-dadd4d98d0d7@wizmail.org>

On 10/04/2019 11:15, Hubert Kario wrote:
> On Wednesday, 10 April 2019 12:05:21 CEST Jeremy Harris wrote:
>> On 10/04/2019 01:25, Viktor Dukhovni wrote:
>>> With TLS 1.0, 1.1 and 1.2, the the (always new IIRC) session object
>>> associated with the connection object at the completion of each
>>> handshake, will contain any fresh tickets issued by the server.
>>
>> That does not match my observation.
> 
> that assumes that the server sends tickets in the first place... but the point 
> stands, the TLS 1.2 server cannot provide a session ticket to the client after 
> the handshake finished (client received server's Finished message), same for 
> even older protocols

I'm not saying the new ticket arrived after the handshake.  I can
see the notification of it arriving during the handshake.  Yet
the session dumped via i2d... after the handshake is bitwise identical
to that given to d2i... , SSL_set_session before the handshake.
-- 
Cheers,
  Jeremy

From Gael.Guegan at non.se.com  Wed Apr 10 11:21:45 2019
From: Gael.Guegan at non.se.com (Gael GUEGAN)
Date: Wed, 10 Apr 2019 11:21:45 +0000
Subject: Troubles using Openssl ENGINE
Message-ID: <DB6PR0401MB250118627CFE1BD4FC2A6527DC2E0@DB6PR0401MB2501.eurprd04.prod.outlook.com>

Hello all,

I am currently having some trouble using an openssl engine with nginx.

I was having no problems using it for loading private key through my engine.
However after adding new capabilities about symmetric encryption (AES) to the engine, nginx is trying to use my engine instead of the default openssl implementation at some point.

And so the handshake is failing, trying to use the symmetric encryption of my engine that I don't want him to use, here a debug log :

2019/04/09 09:34:37 [debug] 9414#0: epoll timer: 59601
2019/04/09 09:34:37 [debug] 9414#0: epoll: fd:3 ev:0001 d:B6973109
2019/04/09 09:34:37 [debug] 9414#0: *3 SSL handshake handler: 0
Init Cipher Key ... (Debug Log from the engine code)
Cleaning up ... (Debug Log from the engine code)
2019/04/09 09:34:37 [debug] 9414#0: *3 SSL_do_handshake: -1
2019/04/09 09:34:37 [debug] 9414#0: *3 SSL_get_error: 1
2019/04/09 09:34:37 [crit] 9414#0: *3 SSL_do_handshake() failed (SSL: error:8009D064:tpm2-tss-engine:tpm2_cipher_init_key:Failed to read TPM2 data) while SSL handshaking, client: 192.168.13
2019/04/09 09:34:37 [debug] 9414#0: *3 close http connection: 3
2019/04/09 09:34:37 [debug] 9414#0: *3 event timer del: 3: 24375741
2019/04/09 09:34:37 [debug] 9414#0: *3 reusable connection: 0

My idea was to disable the symmetric functionality of the engine. And I have attempted to modify the file ngx_event_openssl.c by calling the function ENGINE_unregister_ciphers(...) or ENGINE_set_default(engine, ENGINE_METHOD_PKEY_METHS) or configuring the openssl.cnf with only RSA algo.
I have succeeded to do it in a small c code of mine, but in nginx it is like some function are resetting my configuration like SSL_CTX_new().

Is someone has an idea on how to resolve my problems ? I would highly appreciate some help.

Other information :
~$ sudo /usr/sbin/nginx -V
nginx version: nginx/1.12.1
built with OpenSSL 1.1.0h  27 Mar 2018
TLS SNI support enabled
configure arguments: --crossbuild=Linux:arm --with-endian=big --with-int=4 --with-long=4 --with-long-long=8 --with-ptr-size=4 --with-sig-atomic-t=4 --with-size-t=4 --with-off-t=4 --with-time-t=4 --with-sg

Here a link to the engine : https://github.com/tpm2-software/tpm2-tss-engine




Gael GUEGAN

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

From richmoore44 at gmail.com  Wed Apr 10 11:37:15 2019
From: richmoore44 at gmail.com (Richard Moore)
Date: Wed, 10 Apr 2019 12:37:15 +0100
Subject: Listing TLS 1.3 Ciphers
Message-ID: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>

Hi All,

I haven't found a way to list the supported openssl ciphers from the
command line (i.e. get the list of potential values for -ciphersuites). I
understand that currently there are only 5 options however this could
change over time, so I wanted to avoid hard coding the list in a script. Am
I missing something?

Thanks

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

From geekinthelead at gmail.com  Wed Apr 10 12:28:58 2019
From: geekinthelead at gmail.com (Kingsley O)
Date: Wed, 10 Apr 2019 13:28:58 +0100
Subject: C:\Users\xxx\xx\xxx\openssl\e_os.h(13): fatal error C1083: Cannot
 open include file: 'limits.h': No such file or directory
Message-ID: <CAGQ2jNCWTufzHM2c3eN20ZsDCFwLzcss8e1W3kMSVXvGzt7jWA@mail.gmail.com>

Hello,

I get the above error when trying to build openssl. I am on a x64 Windows
10 platform, using perl 5, version 26, subversion 3 (v5.26.3) built for
MSWin32-x64-multi-thread and Visual studio express for Windows 10

The file limits is clearly located within the include folder of my visual
studio installation and I have my environment variable set so that i can
build openssl outside of the source tree. Unfortunately, I am at a loss as
to why the build is unable to find this file.
I have tried running vcvars32.bat and vcvarsx86_amd64.bat prior to running
the configure and build scripts but have not been successful on both
occasions.

In addition when i run the Configure script, I would normally select
VC-WIN64A, and I have also tried  running vsvars32.bat prior to running the
Configure and make scripts

Sometimes I get similar error with the build unable to find a different
file, in this instance *winsock2.h*

Can any of you kind folk please help?  I hope you can see my screenshot

Many Thanks in advance

*C:\Users\hello\_DEV\3di\openssl>nmake*

*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*

*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
<http://dofile.pl>"  "-omakefile" "crypto\include\internal\bn_conf.h.in
<http://bn_conf.h.in>" > crypto\include\internal\bn_conf.h*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
<http://dofile.pl>"  "-omakefile" "crypto\include\internal\dso_conf.h.in
<http://dso_conf.h.in>" > crypto\include\internal\dso_conf.h*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
<http://dofile.pl>"  "-omakefile" "doc\man7\openssl_user_macros.pod.in
<http://openssl_user_macros.pod.in>" > doc\man7\openssl_user_macros.pod*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
<http://dofile.pl>"  "-omakefile" "include\openssl\opensslconf.h.in
<http://opensslconf.h.in>" > include\openssl\opensslconf.h*
*        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl
<http://dofile.pl>"  "-omakefile" "test\provider_internal_test.conf.in
<http://provider_internal_test.conf.in>" > test\provider_internal_test.conf*
*        "C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\BIN\nmake.exe" /                   depend && "C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" /
 _all*

*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*


*Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
*Copyright (C) Microsoft Corporation.  All rights reserved.*

*        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
/O2 /I "." /I "include" /I "apps\include" -D"L_ENDIAN" -D"OPENSSL_PIC"
-D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
-D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
-D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM"
-D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM"
-D"X25519_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common
Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-3\""
-D"MODULESDIR=\"C:\\Program Files\\OpenSSL\\lib\\ossl-modules\""
-D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"   -c /Foapps\libapps-lib-app_rand.obj
"apps\app_rand.c"*
*app_rand.c*
*C:\Users\hello\_DEV\3di\openssl\e_os.h(129): fatal error C1083: Cannot
open include file: 'winsock2.h': No such file or directory*
*NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\BIN\cl.EXE"' : return code '0x2'*
*Stop.*
*NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'*
*Stop.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190410/d6a1b4b4/attachment.html>

From jb-openssl at wisemo.com  Wed Apr 10 13:58:02 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 10 Apr 2019 15:58:02 +0200
Subject: C:\Users\xxx\xx\xxx\openssl\e_os.h(13): fatal error C1083: Cannot
 open include file: 'limits.h': No such file or directory
In-Reply-To: <CAGQ2jNCWTufzHM2c3eN20ZsDCFwLzcss8e1W3kMSVXvGzt7jWA@mail.gmail.com>
References: <CAGQ2jNCWTufzHM2c3eN20ZsDCFwLzcss8e1W3kMSVXvGzt7jWA@mail.gmail.com>
Message-ID: <094beacb-6b42-9012-2546-9781dc0a4342@wisemo.com>

On 10/04/2019 14:28, Kingsley O wrote:
> Hello,
>
> I get the above error when trying to build openssl. I am on a x64 
> Windows 10 platform, using?perl 5, version 26, subversion 3 (v5.26.3) 
> built for MSWin32-x64-multi-thread and Visual studio express for 
> Windows 10
>
> The file limits is clearly located within the include folder of my 
> visual studio installation and I have my environment variable set so 
> that i can build openssl outside of the source tree. Unfortunately, I 
> am at a loss as to why the build is unable to find this file.
> I have tried running vcvars32.bat and?vcvarsx86_amd64.bat prior to 
> running the configure and build scripts but have not been successful 
> on both occasions.
>
> In addition when i run the Configure script, I would normally select 
> VC-WIN64A, and I have also tried? running vsvars32.bat prior to 
> running the Configure and make scripts
>
> Sometimes I get similar error with the build unable to find a 
> different file, in this instance *winsock2.h*
> *
> *
> Can any of you kind folk please help?? I hope you can see my screenshot
>
> Many Thanks in advance
>
> *C:\Users\hello\_DEV\3di\openssl>nmake*
> *
> *
> *Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
> *Copyright (C) Microsoft Corporation.? All rights reserved.*
> *
> *
> *? ? ? ? "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
> <http://dofile.pl>" "-omakefile" "crypto\include\internal\bn_conf.h.in 
> <http://bn_conf.h.in>" > crypto\include\internal\bn_conf.h*
> *? ? ? ? "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
> <http://dofile.pl>" "-omakefile" 
> "crypto\include\internal\dso_conf.h.in <http://dso_conf.h.in>" > 
> crypto\include\internal\dso_conf.h*
> *? ? ? ? "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
> <http://dofile.pl>" "-omakefile" "doc\man7\openssl_user_macros.pod.in 
> <http://openssl_user_macros.pod.in>" > doc\man7\openssl_user_macros.pod*
> *? ? ? ? "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
> <http://dofile.pl>" "-omakefile" "include\openssl\opensslconf.h.in 
> <http://opensslconf.h.in>" > include\openssl\opensslconf.h*
> *? ? ? ? "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl 
> <http://dofile.pl>" "-omakefile" "test\provider_internal_test.conf.in 
> <http://provider_internal_test.conf.in>" > 
> test\provider_internal_test.conf*
> *? ? ? ? "C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\BIN\nmake.exe" /? ? ? ? ? ? ? ? ? ?depend && "C:\Program Files 
> (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" /? ? ? ? ? ? ? ? 
> ? ?_all*
> *
> *
> *Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
> *Copyright (C) Microsoft Corporation.? All rights reserved.*
> *
> *
> *
> *
> *Microsoft (R) Program Maintenance Utility Version 14.00.24210.0*
> *Copyright (C) Microsoft Corporation.? All rights reserved.*
> *
> *
> *? ? ? ? cl? /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 
> /nologo /O2 /I "." /I "include" /I "apps\include" -D"L_ENDIAN" 
> -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" 
> -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5" 
> -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM" 
> -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" 
> -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" 
> -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common 
> Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program 
> Files\\OpenSSL\\lib\\engines-3\"" -D"MODULESDIR=\"C:\\Program 
> Files\\OpenSSL\\lib\\ossl-modules\"" -D"OPENSSL_SYS_WIN32" 
> -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" 
> -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" 
> -D"OPENSSL_USE_APPLINK" -D"NDEBUG"? ?-c 
> /Foapps\libapps-lib-app_rand.obj "apps\app_rand.c"*
> *app_rand.c*
> *C:\Users\hello\_DEV\3di\openssl\e_os.h(129): fatal error C1083: 
> Cannot open include file: 'winsock2.h': No such file or directory*
> *NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
> Studio 14.0\VC\BIN\cl.EXE"' : return code '0x2'*
> *Stop.*
> *NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
> Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'*
> *Stop.*
>
Check the value of the "INCLUDE" environment variable.? If it is
not set, try the build again from a "Developer Command Prompt"
(Under "%ProgramData%\Microsoft\Windows\Start Menu\Programs\Visual 
Studio 2015\Visual Studio Tools" )


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 francois.gelis at gmail.com  Wed Apr 10 14:11:01 2019
From: francois.gelis at gmail.com (Francois Gelis)
Date: Wed, 10 Apr 2019 16:11:01 +0200
Subject: Issue with smartcard authentication for openvpn
Message-ID: <CAM1xzG1X-iERU2ZXFS_m_VqCKOwjt_gD8oi0F8J5h38Xx+FQ9A@mail.gmail.com>

Hi all,

I have a working openvpn setup with client certificate and private key
stored on my laptop. Then, I have loaded them into a smartcard (Yubico 5
NFC), and modified accordingly the openvpn client config. But running the
openvpn client now fails with an error that seems to originate inside
openssl. Here is a verbose openvpn log (only the portion that seems
relevant for this error, but I have the full log if useful):

Sat Apr  6 15:57:20 2019 us=467260 Incoming Ciphertext -> TLS
Sat Apr  6 15:57:20 2019 us=467271 SSL state (connect): SSLv3/TLS read
server hello
Sat Apr  6 15:57:20 2019 us=467468 VERIFY OK: depth=1, CN=FG-CA
Sat Apr  6 15:57:20 2019 us=467598 VERIFY KU OK
Sat Apr  6 15:57:20 2019 us=467609 Validating certificate extended key usage
Sat Apr  6 15:57:20 2019 us=467615 ++ Certificate has EKU (str) TLS Web
Server Authentication, expects TLS Web Server Authentication
Sat Apr  6 15:57:20 2019 us=467620 VERIFY EKU OK
Sat Apr  6 15:57:20 2019 us=467625 VERIFY OK: depth=0, CN=tx2
Sat Apr  6 15:57:20 2019 us=467650 SSL state (connect): SSLv3/TLS read
server certificate
Sat Apr  6 15:57:20 2019 us=467735 SSL state (connect): SSLv3/TLS read
server key exchange
Sat Apr  6 15:57:20 2019 us=467763 SSL state (connect): SSLv3/TLS read
server certificate request
Sat Apr  6 15:57:20 2019 us=467771 SSL state (connect): SSLv3/TLS read
server done
Sat Apr  6 15:57:20 2019 us=467845 SSL state (connect): SSLv3/TLS write
client certificate
Sat Apr  6 15:57:20 2019 us=468012 SSL state (connect): SSLv3/TLS write
client key exchange
Sat Apr  6 15:57:20 2019 us=468053 PKCS#11: __pkcs11h_openssl_rsa_enc
entered - flen=256, from=0x559d078d6e70, to=0x559d078d6bc0,
rsa=0x559d078b3630, padding=3
Sat Apr  6 15:57:20 2019 us=468060 PKCS#11: __pkcs11h_openssl_rsa_enc -
return rv=112-'CKR_MECHANISM_INVALID'
Sat Apr  6 15:57:20 2019 us=468070 SSL alert (write): fatal: internal error
Sat Apr  6 15:57:20 2019 us=468085 OpenSSL: error:141F0006:SSL
routines:tls_construct_cert_verify:EVP lib
Sat Apr  6 15:57:20 2019 us=468092 TLS_ERROR: BIO read tls_read_plaintext
error
Sat Apr  6 15:57:20 2019 us=468097 TLS Error: TLS object -> incoming
plaintext read error
Sat Apr  6 15:57:20 2019 us=468101 TLS Error: TLS handshake failed

Somehow, it seems that __pkcs11h_openssl_rsa_enc was called with an
unexpected padding. Any ideas on what might be the cause of this?

Best regards,
Francois
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190410/d5670644/attachment-0001.html>

From selva.nair at gmail.com  Wed Apr 10 15:01:10 2019
From: selva.nair at gmail.com (Selva Nair)
Date: Wed, 10 Apr 2019 11:01:10 -0400
Subject: Issue with smartcard authentication for openvpn
In-Reply-To: <CAM1xzG1X-iERU2ZXFS_m_VqCKOwjt_gD8oi0F8J5h38Xx+FQ9A@mail.gmail.com>
References: <CAM1xzG1X-iERU2ZXFS_m_VqCKOwjt_gD8oi0F8J5h38Xx+FQ9A@mail.gmail.com>
Message-ID: <CAKuzo_g6A9g0r69Fg=25jQgZ1jpJtq=R1dvD+rHa9WY7WWfNwA@mail.gmail.com>

Hi,

On Wed, Apr 10, 2019 at 10:11 AM Francois Gelis <francois.gelis at gmail.com>
wrote:

> Hi all,
>
> I have a working openvpn setup with client certificate and private key
> stored on my laptop. Then, I have loaded them into a smartcard (Yubico 5
> NFC), and modified accordingly the openvpn client config. But running the
> openvpn client now fails with an error that seems to originate inside
> openssl. Here is a verbose openvpn log (only the portion that seems
> relevant for this error, but I have the full log if useful):
>
> Sat Apr  6 15:57:20 2019 us=467260 Incoming Ciphertext -> TLS
> Sat Apr  6 15:57:20 2019 us=467271 SSL state (connect): SSLv3/TLS read
> server hello
> Sat Apr  6 15:57:20 2019 us=467468 VERIFY OK: depth=1, CN=FG-CA
> Sat Apr  6 15:57:20 2019 us=467598 VERIFY KU OK
> Sat Apr  6 15:57:20 2019 us=467609 Validating certificate extended key
> usage
> Sat Apr  6 15:57:20 2019 us=467615 ++ Certificate has EKU (str) TLS Web
> Server Authentication, expects TLS Web Server Authentication
> Sat Apr  6 15:57:20 2019 us=467620 VERIFY EKU OK
> Sat Apr  6 15:57:20 2019 us=467625 VERIFY OK: depth=0, CN=tx2
> Sat Apr  6 15:57:20 2019 us=467650 SSL state (connect): SSLv3/TLS read
> server certificate
> Sat Apr  6 15:57:20 2019 us=467735 SSL state (connect): SSLv3/TLS read
> server key exchange
> Sat Apr  6 15:57:20 2019 us=467763 SSL state (connect): SSLv3/TLS read
> server certificate request
> Sat Apr  6 15:57:20 2019 us=467771 SSL state (connect): SSLv3/TLS read
> server done
> Sat Apr  6 15:57:20 2019 us=467845 SSL state (connect): SSLv3/TLS write
> client certificate
> Sat Apr  6 15:57:20 2019 us=468012 SSL state (connect): SSLv3/TLS write
> client key exchange
> Sat Apr  6 15:57:20 2019 us=468053 PKCS#11: __pkcs11h_openssl_rsa_enc
> entered - flen=256, from=0x559d078d6e70, to=0x559d078d6bc0,
> rsa=0x559d078b3630, padding=3
>

padding = 3 means "no padding" indicating that the data for signature is
already padded. That's why the data size (flen) is 256 (hashed data padded
to the rsa key size of 2048 bits, I guess). If you are using OpenSSL 1.1.1,
this could be due to PSS padding in which case current implementation
passes pre-padded data for raw signature to the callback. AFAIK,
pkcs11-helper only handles PKCS1 padding (CKM_RSA_PKCS) though pkcs11
standard does support raw signatures.

A work around may be to restrict TLS version to 1.1 which is not ideal. Not
sure whether openssl has any config options to restrict signature
algorithms.

Sat Apr  6 15:57:20 2019 us=468060 PKCS#11: __pkcs11h_openssl_rsa_enc -
> return rv=112-'CKR_MECHANISM_INVALID'
>
>
Sat Apr  6 15:57:20 2019 us=468070 SSL alert (write): fatal: internal error
> Sat Apr  6 15:57:20 2019 us=468085 OpenSSL: error:141F0006:SSL
> routines:tls_construct_cert_verify:EVP lib
> Sat Apr  6 15:57:20 2019 us=468092 TLS_ERROR: BIO read tls_read_plaintext
> error
> Sat Apr  6 15:57:20 2019 us=468097 TLS Error: TLS object -> incoming
> plaintext read error
> Sat Apr  6 15:57:20 2019 us=468101 TLS Error: TLS handshake failed
>
> Somehow, it seems that __pkcs11h_openssl_rsa_enc was called with an
> unexpected padding. Any ideas on what might be the cause of this?
>

pkcs11-helper needs to be patched to support raw signatures.

Selva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190410/221938de/attachment.html>

From antiac at gmail.com  Wed Apr 10 15:39:35 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Wed, 10 Apr 2019 17:39:35 +0200
Subject: Issue with smartcard authentication for openvpn
In-Reply-To: <CAKuzo_g6A9g0r69Fg=25jQgZ1jpJtq=R1dvD+rHa9WY7WWfNwA@mail.gmail.com>
References: <CAM1xzG1X-iERU2ZXFS_m_VqCKOwjt_gD8oi0F8J5h38Xx+FQ9A@mail.gmail.com>
 <CAKuzo_g6A9g0r69Fg=25jQgZ1jpJtq=R1dvD+rHa9WY7WWfNwA@mail.gmail.com>
Message-ID: <CAPN6PEQm-92k6E9tVE6jBKscMLiW1MqgWGNziEzDsQnjo3ogiA@mail.gmail.com>

> padding = 3 means "no padding" indicating that the data for signature is already padded. That's why the data size (flen) is 256 (hashed data padded to the rsa key size of 2048 bits, I guess). If you are using OpenSSL 1.1.1, this could be due to PSS padding in which case current implementation passes pre-padded data for raw signature to the callback. AFAIK, pkcs11-helper only handles PKCS1 padding (CKM_RSA_PKCS) though pkcs11 standard does support raw signatures.

https://github.com/OpenSC/pkcs11-helper/blob/0e2ae10ef9611beef92457171e8c78d8e936dfca/lib/pkcs11h-openssl.c#L570

if (padding != RSA_PKCS1_PADDING) {
rv = CKR_MECHANISM_INVALID;
goto cleanup;
}

From dclarke at blastwave.org  Wed Apr 10 16:13:27 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Wed, 10 Apr 2019 12:13:27 -0400
Subject: Listing TLS 1.3 Ciphers
In-Reply-To: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>
References: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>
Message-ID: <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>

On 4/10/19 7:37 AM, Richard Moore wrote:
> Hi All,
> 
> I haven't found a way to list the supported openssl ciphers from the 
> command line (i.e. get the list of potential values for -ciphersuites). 
> I understand that currently there are only 5 options however this could 
> change over time, so I wanted to avoid hard coding the list in a script. 
> Am I?missing something?
> 
> Thanks
> 
> Rich

Strangely I only see three :

nix$ openssl version
OpenSSL 1.1.1b  26 Feb 2019
nix$ openssl ciphers -V -tls1_3 -s
           0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any 
Au=any  Enc=AESGCM(256) Mac=AEAD
           0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any 
Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
           0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any 
Au=any  Enc=AESGCM(128) Mac=AEAD
nix$

Very odd. I thought that there were more at one point.

From matt at openssl.org  Wed Apr 10 16:24:09 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Apr 2019 17:24:09 +0100
Subject: Listing TLS 1.3 Ciphers
In-Reply-To: <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>
References: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>
 <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>
Message-ID: <bb3eb603-c2f7-f4c2-b11e-442e671f1415@openssl.org>



On 10/04/2019 17:13, Dennis Clarke wrote:
> On 4/10/19 7:37 AM, Richard Moore wrote:
>> Hi All,
>>
>> I haven't found a way to list the supported openssl ciphers from the command
>> line (i.e. get the list of potential values for -ciphersuites). I understand
>> that currently there are only 5 options however this could change over time,
>> so I wanted to avoid hard coding the list in a script. Am I?missing something?
>>
>> Thanks
>>
>> Rich
> 
> Strangely I only see three :
> 
> nix$ openssl version
> OpenSSL 1.1.1b? 26 Feb 2019
> nix$ openssl ciphers -V -tls1_3 -s
> ????????? 0x13,0x02 - TLS_AES_256_GCM_SHA384? TLSv1.3 Kx=any Au=any?
> Enc=AESGCM(256) Mac=AEAD
> ????????? 0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any?
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ????????? 0x13,0x01 - TLS_AES_128_GCM_SHA256? TLSv1.3 Kx=any Au=any?
> Enc=AESGCM(128) Mac=AEAD
> nix$
> 
> Very odd. I thought that there were more at one point.
> 

There are 5 but only 3 are enabled by default. I'm not sure it is possible to
get "openssl ciphers" to list all of the ones it knows about. You have to
explicitly list them in the "-ciphersuites" option. Probably we should add that
capability.

Matt

From bkaduk at akamai.com  Wed Apr 10 16:25:09 2019
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 10 Apr 2019 11:25:09 -0500
Subject: Listing TLS 1.3 Ciphers
In-Reply-To: <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>
References: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>
 <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>
Message-ID: <20190410162508.GD6282@akamai.com>

On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote:
> On 4/10/19 7:37 AM, Richard Moore wrote:
> >Hi All,
> >
> >I haven't found a way to list the supported openssl ciphers from the
> >command line (i.e. get the list of potential values for -ciphersuites). I
> >understand that currently there are only 5 options however this could
> >change over time, so I wanted to avoid hard coding the list in a script.
> >Am I?missing something?
> >
> >Thanks
> >
> >Rich
> 
> Strangely I only see three :
> 
> nix$ openssl version
> OpenSSL 1.1.1b  26 Feb 2019
> nix$ openssl ciphers -V -tls1_3 -s
>           0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any Au=any
> Enc=AESGCM(256) Mac=AEAD
>           0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
>           0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any Au=any
> Enc=AESGCM(128) Mac=AEAD
> nix$
> 
> Very odd. I thought that there were more at one point.

The ones with truncated (8-byte) authentication tag are not intended for
general use and don't make it into the default list.

-Ben

From dclarke at blastwave.org  Wed Apr 10 16:32:00 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Wed, 10 Apr 2019 12:32:00 -0400
Subject: Listing TLS 1.3 Ciphers
In-Reply-To: <20190410162508.GD6282@akamai.com>
References: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>
 <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>
 <20190410162508.GD6282@akamai.com>
Message-ID: <b2fe586d-2219-dfd0-a99d-1f25d7fb39cc@blastwave.org>


> 
> The ones with truncated (8-byte) authentication tag are not intended for
> general use and don't make it into the default list.

There must be a Configuration option in 10-main.conf to enable them also?

Dennis



From Michal.Trojnara at stunnel.org  Wed Apr 10 18:36:59 2019
From: Michal.Trojnara at stunnel.org (Michal Trojnara)
Date: Wed, 10 Apr 2019 20:36:59 +0200
Subject: stunnel 5.53 released
Message-ID: <0a2905c6-7e89-1e2e-03a5-35731a062728@stunnel.org>

Dear Users,

I have released version 5.53 of stunnel.

Version 5.53, 2019.04.10, urgency: HIGH
* Bugfixes
? - Fixed data transfer stalls introduced in stunnel 5.51.
* New features
? - Android binary updated to support Android 4.x.

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

SHA-256 hashes:
80439896ee14269eb70bc8bc669433c7d619018a62c9f9c5c760a24515302585?
stunnel-5.53.tar.gz
4f2d24d08f547943b8a499d411425409a52973a349c9120c650ba77d3f29ef79?
stunnel-5.53-win64-installer.exe
e619880f4fc25a7a4869cace9f6e6f3f5940cfdb764ed9987d892d9e9b0ea35d?
stunnel-5.53-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/20190410/418c2968/attachment.sig>

From richmoore44 at gmail.com  Wed Apr 10 21:06:26 2019
From: richmoore44 at gmail.com (Richard Moore)
Date: Wed, 10 Apr 2019 22:06:26 +0100
Subject: Listing TLS 1.3 Ciphers
In-Reply-To: <20190410162508.GD6282@akamai.com>
References: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>
 <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>
 <20190410162508.GD6282@akamai.com>
Message-ID: <CAMp7mVvKJcpgODfBnyr+uimRnqzBsWzE3=ekazZg5_Rw5Qns3Q@mail.gmail.com>

On Wed, 10 Apr 2019 at 17:25, Benjamin Kaduk via openssl-users <
openssl-users at openssl.org> wrote:

> On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote:
>
> > Very odd. I thought that there were more at one point.
>
> The ones with truncated (8-byte) authentication tag are not intended for
> general use and don't make it into the default list.
>

They also don't appear if you explicitly try to list 'All' which is what I
found surprising.

Rich



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

From mcr+ietf at sandelman.ca  Wed Apr 10 23:06:48 2019
From: mcr+ietf at sandelman.ca (Michael Richardson)
Date: Wed, 10 Apr 2019 19:06:48 -0400
Subject: Listing TLS 1.3 Ciphers
In-Reply-To: <20190410162508.GD6282@akamai.com>
References: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>
 <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>
 <20190410162508.GD6282@akamai.com>
Message-ID: <21327.1554937608@dooku.sandelman.ca>


Benjamin Kaduk via openssl-users <openssl-users at openssl.org> wrote:
    >> Very odd. I thought that there were more at one point.

    > The ones with truncated (8-byte) authentication tag are not intended
    > for general use and don't make it into the default list.

I think that those are the ones that constrained devices prefer,
such as ECDHE-ECDSA-AES128-CCM8?
So is there a way to validate that they are available, that there were
compiled in?

--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190410/262133a1/attachment.sig>

From matt at openssl.org  Thu Apr 11 08:37:45 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Apr 2019 09:37:45 +0100
Subject: Listing TLS 1.3 Ciphers
In-Reply-To: <CAMp7mVvKJcpgODfBnyr+uimRnqzBsWzE3=ekazZg5_Rw5Qns3Q@mail.gmail.com>
References: <CAMp7mVtm84Nm89+-q+mNFOXKcWLqbpHR4L__+jYH-2-57JvcXQ@mail.gmail.com>
 <d0ed529d-4c83-fe42-38b7-15b4ba2cd014@blastwave.org>
 <20190410162508.GD6282@akamai.com>
 <CAMp7mVvKJcpgODfBnyr+uimRnqzBsWzE3=ekazZg5_Rw5Qns3Q@mail.gmail.com>
Message-ID: <38d2dfc5-4a0d-946d-dbac-3d39518fd0cf@openssl.org>



On 10/04/2019 22:06, Richard Moore wrote:
> They also don't appear if you explicitly try to list 'All' which is what I found
> surprising.

"ALL" is a TLSv1.2 cipherstring and has no impact on the TLSv1.3 ciphersuite
selection. The two sets of ciphersuites are configured separately.


On 11/04/2019 00:06, Michael Richardson wrote:
> I think that those are the ones that constrained devices prefer,
> such as ECDHE-ECDSA-AES128-CCM8?
> So is there a way to validate that they are available, that there were
> compiled in?

You can get "openssl ciphers" to show them if you explicitly ask for them, i.e.

$ openssl ciphers -v -ciphersuites
"TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256"
| grep "TLSv1.3"
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any
Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
TLS_AES_128_CCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESCCM(128) Mac=AEAD
TLS_AES_128_CCM_8_SHA256 TLSv1.3 Kx=any      Au=any  Enc=AESCCM8(128) Mac=AEAD


Matt

From Chethan.Kumar at toshiba-tsip.com  Thu Apr 11 10:55:17 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Thu, 11 Apr 2019 10:55:17 +0000
Subject: How to disable tls 1.0 and tls 1.1
Message-ID: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>

Dear all,

Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 while compiling openssl package.
I am using 1.0.2n openssl version and disabled SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2.

I also have a doubt on difference between -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2.
Can someone please explain the difference.

Thanks in advance,
Chethan Kumar

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190411/c54119bb/attachment-0001.html>

From swamy.j-s at in.abb.com  Thu Apr 11 12:06:29 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Thu, 11 Apr 2019 12:06:29 +0000
Subject: ASN1_CTX usage in openssl 1.1.0
Message-ID: <HE1PR0602MB36436FDFECD6124D20CC7056962F0@HE1PR0602MB3643.eurprd06.prod.outlook.com>

I have upgraded openssl from 1.0.2n to 1.1.0g on Ubuntu 18.04 recently. My application uses openssl. Now during build am facing some issues.



i used "EVP_MD_CTX ctx" earlier and now i modified it has



"EVP_MD_CTX *ctx

ctx=EVP_MD_CTX_new()" and this is working fine.



And i used "ASN1_CTX ctx" but this is not working if modify like above. And during build its suggesting to use "ASN1_SCTX ctx" but if I use this then I get error in "M_ASN1_New_Malloc"



So how to modify "ASN1_CTX ctx" in openssl 1.1.0g.



Also am getting error as /usr/include/openssl/asn1_mac.h:10:2: error: #error "This file is obsolete; please update your software."


Thanks and Regards,
SWAMY J S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190411/341ebc1a/attachment.html>

From matt at openssl.org  Thu Apr 11 13:03:22 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Apr 2019 14:03:22 +0100
Subject: ASN1_CTX usage in openssl 1.1.0
In-Reply-To: <HE1PR0602MB36436FDFECD6124D20CC7056962F0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB36436FDFECD6124D20CC7056962F0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <025f8407-a556-1d2b-ebca-9e67acf4cdf1@openssl.org>



On 11/04/2019 13:06, Swamy J-S wrote:
> 
> And i used *?ASN1_CTX ctx?* but this is not working if modify like above. And
> during build its suggesting to use *?ASN1_SCTX ctx?* but if I use this then I
> get error in *?M_ASN1_New_Malloc?*
> 
> So how to modify ?*ASN1_CTX ctx*? in openssl 1.1.0g.
> 
> Also am getting error as?/usr/include/openssl/asn1_mac.h:10:2: error: #error
> "This file is obsolete; please update your software."
> 

You are using the old ASN1 API which has been obsolete since 2002. Are you
reading/writing your own custom ASN1 structures? If so then that will need to be
rewritten.

See my recent post on this topic:

https://mta.openssl.org/pipermail/openssl-users/2019-April/010239.html

Matt


From Chethan.Kumar at toshiba-tsip.com  Thu Apr 11 13:25:51 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Thu, 11 Apr 2019 13:25:51 +0000
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
Message-ID: <447C096A3E2889439233CDD6DAB29F95ADE2C193@tosblrmbx04.TOSHIBA-TSIP.COM>

Adding to previous mail,
We tried -DSSL_OP_NO_TLSv1   -DSSL_OP_NO_TLSv1_1  along with disabling SSLv2 and v1 but still client hello is sent using min and max as TLS1.0 and TLS1.2.

Any idea what is wrong in our options and what should be used instead.?

Thanks in advance,
Chethan Kumar

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Chethan Kumar
Sent: Thursday, April 11, 2019 4:25 PM
To: openssl-users at openssl.org
Subject: How to disable tls 1.0 and tls 1.1

Dear all,

Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 while compiling openssl package.
I am using 1.0.2n openssl version and disabled SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2.

I also have a doubt on difference between -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2.
Can someone please explain the difference.

Thanks in advance,
Chethan Kumar


The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the
recipient and may contain privileged information. If you are not the intended recipient, please notify the
sender and delete the message along with any attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190411/07a0acaa/attachment.html>

From hkario at redhat.com  Thu Apr 11 13:37:56 2019
From: hkario at redhat.com (Hubert Kario)
Date: Thu, 11 Apr 2019 15:37:56 +0200
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95ADE2C193@tosblrmbx04.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <447C096A3E2889439233CDD6DAB29F95ADE2C193@tosblrmbx04.TOSHIBA-TSIP.COM>
Message-ID: <1795492.ynIg8kXk7G@pintsize.usersys.redhat.com>

On Thursday, 11 April 2019 15:25:51 CEST Chethan Kumar wrote:
> Adding to previous mail,
> We tried -DSSL_OP_NO_TLSv1   -DSSL_OP_NO_TLSv1_1  along with disabling SSLv2
> and v1 but still client hello is sent using min and max as TLS1.0 and
> TLS1.2.

there is no "min" version in Client Hello, the version in record layer is 
irrelevant and used only for backwards compatibility *NOT* for negotiation

> Any idea what is wrong in our options and what should be used instead.?

compile an openssl server with TLS 1.1 enabled, run openssl s_server -tls1_1 
to enable just TLS 1.1 and see if your production compile can connect

> Thanks in advance,
> Chethan Kumar
> 
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Chethan Kumar Sent: Thursday, April 11, 2019 4:25 PM
> To: openssl-users at openssl.org
> Subject: How to disable tls 1.0 and tls 1.1
> 
> Dear all,
> 
> Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 while
> compiling openssl package. I am using 1.0.2n openssl version and disabled
> SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and
> -DOPENSSL_NO_SSL2.
> 
> I also have a doubt on difference between -DSSL_OP_NO_SSLv2,
> -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2. Can someone please explain the
> difference.
> 
> Thanks in advance,
> Chethan Kumar
> 
> 
> The information contained in this e-mail message and in any
> attachments/annexure/appendices is confidential to the recipient and may
> contain privileged information. If you are not the intended recipient,
> please notify the sender and delete the message along with any
> attachments/annexure/appendices. You should not disclose, copy or otherwise
> use the information contained in the message or any annexure. Any views
> expressed in this e-mail are those of the individual sender except where
> the sender specifically states them to be the views of Toshiba Software
> India Pvt. Ltd. (TSIP),Bangalore.
> Although this transmission and any attachments are believed to be free of
> any virus or other defect that might affect any computer system into which
> it is received and opened, it is the responsibility of the recipient to
> ensure that it is virus free and no responsibility is accepted by Toshiba
> Software India Pvt. Ltd, for any loss or damage arising in any way from its
> use. The information contained in this e-mail message and in any
> attachments/annexure/appendices is confidential to the
> recipient and may contain privileged information.
> If you are not the intended recipient, please notify the
> sender and delete the message along with any
> attachments/annexure/appendices. You should not disclose,
> copy or otherwise use the information contained in the
> message or any annexure. Any views expressed in this e-mail
> are those of the individual sender except where the sender
> specifically states them to be the views of
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be
> free of any virus or other defect that might affect any computer
> system into which it is received and opened, it is the responsibility
> of the recipient to ensure that it is virus free and no responsibility
> is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
> damage arising in any way from its use.


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190411/c1fcb469/attachment-0001.sig>

From jb-openssl at wisemo.com  Thu Apr 11 13:50:40 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 11 Apr 2019 15:50:40 +0200
Subject: ASN1_CTX usage in openssl 1.1.0
In-Reply-To: <025f8407-a556-1d2b-ebca-9e67acf4cdf1@openssl.org>
References: <HE1PR0602MB36436FDFECD6124D20CC7056962F0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
 <025f8407-a556-1d2b-ebca-9e67acf4cdf1@openssl.org>
Message-ID: <70f37727-0628-d462-eec4-2f113a2f02f9@wisemo.com>

On 11/04/2019 15:03, Matt Caswell wrote:
>
> On 11/04/2019 13:06, Swamy J-S wrote:
>> And i used *?ASN1_CTX ctx?* but this is not working if modify like above. And
>> during build its suggesting to use *?ASN1_SCTX ctx?* but if I use this then I
>> get error in *?M_ASN1_New_Malloc?*
>>
>> So how to modify ?*ASN1_CTX ctx*? in openssl 1.1.0g.
>>
>> Also am getting error as?/usr/include/openssl/asn1_mac.h:10:2: error: #error
>> "This file is obsolete; please update your software."
>>
> You are using the old ASN1 API which has been obsolete since 2002. Are you
> reading/writing your own custom ASN1 structures? If so then that will need to be
> rewritten.
>
> See my recent post on this topic:
>
> https://mta.openssl.org/pipermail/openssl-users/2019-April/010239.html
Please note that the ~2002 deprecation was confusing, as it wasn't very
clear which set of ASN.1 APIs was the bad one.? Depending on which parts
of the documentation someone read, they could get told to use the old
interface, the new interface or not get told either way.

Personally, I just gave up and didn't use that part of OpenSSL.


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 John.Unsworth at synchronoss.com  Thu Apr 11 14:20:30 2019
From: John.Unsworth at synchronoss.com (John Unsworth)
Date: Thu, 11 Apr 2019 14:20:30 +0000
Subject: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
Message-ID: <DM6PR07MB4650E3F5C694C10F37140339F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>

I have built openssl 1.1.1b 64 bit with VS 2013 on Windows 7. It seems to build fine. However running nmake test gives some fails:

perl Configure VC-WIN64A no-shared --prefix=C:\Downloads\OpenSSL\openssl-1.1.1b\static
make install
make test

test\recipes\30-test_evp.t ...................... Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/9 subteststest\recipes\80-test_ssl_new.t .................. Dubious, test returned 2 (wstat 512, 0x200)

Test Summary Report
-------------------
test\recipes\30-test_evp.t                    (Wstat: 1024 Tests: 9 Failed: 4)
  Failed tests:  2, 5, 7, 9
  Non-zero exit status: 4
test\recipes\80-test_ssl_new.t                (Wstat: 512 Tests: 29 Failed: 2)
  Failed tests:  20, 28
  Non-zero exit status: 2

Thanks,
John Unsworth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190411/8554c8d7/attachment.html>

From matt at openssl.org  Thu Apr 11 16:39:52 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Apr 2019 17:39:52 +0100
Subject: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
In-Reply-To: <DM6PR07MB4650E3F5C694C10F37140339F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
References: <DM6PR07MB4650E3F5C694C10F37140339F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
Message-ID: <bf113179-e246-a690-d723-59d95f04c076@openssl.org>



On 11/04/2019 15:20, John Unsworth wrote:

> test\recipes\30-test_evp.t ...................... Dubious, test returned 4
> (wstat 1024, 0x400)

Can you tell us the result from :

nmake TESTS=test_evp V=1 test

Thanks

Matt


From John.Unsworth at synchronoss.com  Thu Apr 11 16:43:53 2019
From: John.Unsworth at synchronoss.com (John Unsworth)
Date: Thu, 11 Apr 2019 16:43:53 +0000
Subject: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
In-Reply-To: <bf113179-e246-a690-d723-59d95f04c076@openssl.org>
References: <DM6PR07MB4650E3F5C694C10F37140339F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
 <bf113179-e246-a690-d723-59d95f04c076@openssl.org>
Message-ID: <DM6PR07MB46507E7E2D2026087EAAF918F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>

Attached. This is with the debug build.

John

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: 11 April 2019 17:40
To: openssl-users at openssl.org
Subject: Re: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013

CAUTION: This email originated from outside of Synchronoss.


On 11/04/2019 15:20, John Unsworth wrote:

> test\recipes\30-test_evp.t ...................... Dubious, test 
> returned 4 (wstat 1024, 0x400)

Can you tell us the result from :

nmake TESTS=test_evp V=1 test

Thanks

Matt

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testoutput.txt
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190411/e581a4ec/attachment-0001.txt>

From olopsd at amazon.com  Thu Apr 11 16:47:01 2019
From: olopsd at amazon.com (Olops, Daniel)
Date: Thu, 11 Apr 2019 16:47:01 +0000
Subject: OCSP validation via AIA responders through a proxy
Message-ID: <4732CCEA-249B-4A51-975D-C7D08ED48D0C@amazon.com>

Hello,

I'm finding conflicting information on whether OpenSSL can perform OCSP validation via AIA responders through a proxy. An open issue at GitHub suggests that this is an open feature request (https://github.com/openssl/openssl/issues/6965), however I've seen people saying that a proxy can be specified when using "openssl ocsp" by passing "-host <proxy_host>:<proxy_port>" and "-path <OCSP_AIA_URL>". Which one is correct?

If context matters, this is about having support in stunnel for performing OCSP validation via AIA responders through a proxy. Currently it ignores any *_proxy variables, and consequently validation fails when there's no direct internet access. Research I've done so far suggests that the limitation lies in OpenSSL, not stunnel, hence this email.

Regards,

Daniel O.




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705



From Chethan.Kumar at toshiba-tsip.com  Fri Apr 12 04:47:54 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Fri, 12 Apr 2019 04:47:54 +0000
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <1795492.ynIg8kXk7G@pintsize.usersys.redhat.com>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <447C096A3E2889439233CDD6DAB29F95ADE2C193@tosblrmbx04.TOSHIBA-TSIP.COM>
 <1795492.ynIg8kXk7G@pintsize.usersys.redhat.com>
Message-ID: <447C096A3E2889439233CDD6DAB29F95ADE3033D@TOSBLRMBX03.TOSHIBA-TSIP.COM>

> there is no "min" version in Client Hello, the version in record layer is irrelevant and used only for backwards compatibility *NOT* for negotiation
Thank you for the information. But have a doubt, then what is the importance of SSL_CTX_set_min_proto_version() and SSL_CTX_set_max_proto_version() introduced in 1.1.X along with SSL_CTX_set_options().

I would like to know how to disable TLSv1.0 and 1.1 using configure option[CONFOPTS] in Makefile.

Thanks in advance,
Chethan Kumar


-----Original Message-----
From: Hubert Kario [mailto:hkario at redhat.com] 
Sent: Thursday, April 11, 2019 7:08 PM
To: openssl-users at openssl.org
Cc: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
Subject: Re: How to disable tls 1.0 and tls 1.1

On Thursday, 11 April 2019 15:25:51 CEST Chethan Kumar wrote:
> Adding to previous mail,
> We tried -DSSL_OP_NO_TLSv1   -DSSL_OP_NO_TLSv1_1  along with disabling SSLv2
> and v1 but still client hello is sent using min and max as TLS1.0 and 
> TLS1.2.

there is no "min" version in Client Hello, the version in record layer is irrelevant and used only for backwards compatibility *NOT* for negotiation

> Any idea what is wrong in our options and what should be used instead.?

compile an openssl server with TLS 1.1 enabled, run openssl s_server -tls1_1 to enable just TLS 1.1 and see if your production compile can connect

> Thanks in advance,
> Chethan Kumar
> 
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Chethan Kumar Sent: Thursday, April 11, 2019 4:25 PM
> To: openssl-users at openssl.org
> Subject: How to disable tls 1.0 and tls 1.1
> 
> Dear all,
> 
> Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 while 
> compiling openssl package. I am using 1.0.2n openssl version and 
> disabled
> SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and 
> -DOPENSSL_NO_SSL2.
> 
> I also have a doubt on difference between -DSSL_OP_NO_SSLv2,
> -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2. Can someone please explain 
> the difference.
> 
> Thanks in advance,
> Chethan Kumar
> 
> 
> The information contained in this e-mail message and in any 
> attachments/annexure/appendices is confidential to the recipient and 
> may contain privileged information. If you are not the intended 
> recipient, please notify the sender and delete the message along with 
> any attachments/annexure/appendices. You should not disclose, copy or 
> otherwise use the information contained in the message or any 
> annexure. Any views expressed in this e-mail are those of the 
> individual sender except where the sender specifically states them to 
> be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> Although this transmission and any attachments are believed to be free 
> of any virus or other defect that might affect any computer system 
> into which it is received and opened, it is the responsibility of the 
> recipient to ensure that it is virus free and no responsibility is 
> accepted by Toshiba Software India Pvt. Ltd, for any loss or damage 
> arising in any way from its use. The information contained in this 
> e-mail message and in any attachments/annexure/appendices is 
> confidential to the recipient and may contain privileged information.
> If you are not the intended recipient, please notify the sender and 
> delete the message along with any attachments/annexure/appendices. You 
> should not disclose, copy or otherwise use the information contained 
> in the message or any annexure. Any views expressed in this e-mail are 
> those of the individual sender except where the sender specifically 
> states them to be the views of Toshiba Software India Pvt. Ltd. 
> (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be free 
> of any virus or other defect that might affect any computer system 
> into which it is received and opened, it is the responsibility of the 
> recipient to ensure that it is virus free and no responsibility is 
> accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or 
> damage arising in any way from its use.


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

From hkario at redhat.com  Fri Apr 12 11:20:10 2019
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 12 Apr 2019 13:20:10 +0200
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95ADE3033D@TOSBLRMBX03.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <1795492.ynIg8kXk7G@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE3033D@TOSBLRMBX03.TOSHIBA-TSIP.COM>
Message-ID: <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>

On Friday, 12 April 2019 06:47:54 CEST Chethan Kumar wrote:
> > there is no "min" version in Client Hello, the version in record layer is
> > irrelevant and used only for backwards compatibility *NOT* for
> > negotiation
> Thank you for the information. But have a doubt, then what is the importance
> of SSL_CTX_set_min_proto_version() and SSL_CTX_set_max_proto_version()
> introduced in 1.1.X along with SSL_CTX_set_options().

when the minimum set is higher than what the server answers with, the *client* 
will reject the connection after receiving ServerHello

that is:
when SSL_CTX_set_min_proto_version is set to tls 1.2,
SSL_CTX_set_max_proto_version si set to tls 1.3
and the server replies with ServerHello.version of (3, 2) i.e. TLS 1.1
the client will abort the connection
 
> I would like to know how to disable TLSv1.0 and 1.1 using configure
> option[CONFOPTS] in Makefile.

what evidence you have that what you do is ineffective? 

why you're not using?
./config no-tls1 no-tls1_1

> Thanks in advance,
> Chethan Kumar
> 
> 
> -----Original Message-----
> From: Hubert Kario [mailto:hkario at redhat.com] 
> Sent: Thursday, April 11, 2019 7:08 PM
> To: openssl-users at openssl.org
> Cc: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> Subject: Re: How to disable tls 1.0 and tls 1.1
> 
> On Thursday, 11 April 2019 15:25:51 CEST Chethan Kumar wrote:
> 
> > Adding to previous mail,
> > We tried -DSSL_OP_NO_TLSv1   -DSSL_OP_NO_TLSv1_1  along with disabling
> > SSLv2
 and v1 but still client hello is sent using min and max as TLS1.0
> > and TLS1.2.
> 
> 
> there is no "min" version in Client Hello, the version in record layer is
> irrelevant and used only for backwards compatibility *NOT* for negotiation
> 
> 
> > Any idea what is wrong in our options and what should be used instead.?
> 
> 
> compile an openssl server with TLS 1.1 enabled, run openssl s_server -tls1_1
> to enable just TLS 1.1 and see if your production compile can connect
 
> 
> > Thanks in advance,
> > Chethan Kumar
> > 
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > Behalf Of Chethan Kumar Sent: Thursday, April 11, 2019 4:25 PM
> > To: openssl-users at openssl.org
> > Subject: How to disable tls 1.0 and tls 1.1
> > 
> > Dear all,
> > 
> > Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 while 
> > compiling openssl package. I am using 1.0.2n openssl version and 
> > disabled
> > SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and 
> > -DOPENSSL_NO_SSL2.
> > 
> > I also have a doubt on difference between -DSSL_OP_NO_SSLv2,
> > -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2. Can someone please explain 
> > the difference.
> > 
> > Thanks in advance,
> > Chethan Kumar
> > 
> > 
> > The information contained in this e-mail message and in any 
> > attachments/annexure/appendices is confidential to the recipient and 
> > may contain privileged information. If you are not the intended 
> > recipient, please notify the sender and delete the message along with 
> > any attachments/annexure/appendices. You should not disclose, copy or 
> > otherwise use the information contained in the message or any 
> > annexure. Any views expressed in this e-mail are those of the 
> > individual sender except where the sender specifically states them to 
> > be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> > Although this transmission and any attachments are believed to be free 
> > of any virus or other defect that might affect any computer system 
> > into which it is received and opened, it is the responsibility of the 
> > recipient to ensure that it is virus free and no responsibility is 
> > accepted by Toshiba Software India Pvt. Ltd, for any loss or damage 
> > arising in any way from its use. The information contained in this 
> > e-mail message and in any attachments/annexure/appendices is 
> > confidential to the recipient and may contain privileged information.
> > If you are not the intended recipient, please notify the sender and 
> > delete the message along with any attachments/annexure/appendices. You 
> > should not disclose, copy or otherwise use the information contained 
> > in the message or any annexure. Any views expressed in this e-mail are 
> > those of the individual sender except where the sender specifically 
> > states them to be the views of Toshiba Software India Pvt. Ltd. 
> > (TSIP),Bangalore.
> > 
> > Although this transmission and any attachments are believed to be free 
> > of any virus or other defect that might affect any computer system 
> > into which it is received and opened, it is the responsibility of the 
> > recipient to ensure that it is virus free and no responsibility is 
> > accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or 
> > damage arising in any way from its use.
> 
> 
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
> The information contained in this e-mail message and in any
> attachments/annexure/appendices is confidential to the 
> recipient and may contain privileged information. 
> If you are not the intended recipient, please notify the
> sender and delete the message along with any 
> attachments/annexure/appendices. You should not disclose,
> copy or otherwise use the information contained in the
> message or any annexure. Any views expressed in this e-mail 
> are those of the individual sender except where the sender 
> specifically states them to be the views of 
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be
> free of any virus or other defect that might affect any computer 
> system into which it is received and opened, it is the responsibility
> of the recipient to ensure that it is virus free and no responsibility 
> is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
> damage arising in any way from its use.


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190412/b40bca7e/attachment.sig>

From Chethan.Kumar at toshiba-tsip.com  Fri Apr 12 11:54:24 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Fri, 12 Apr 2019 11:54:24 +0000
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <1795492.ynIg8kXk7G@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE3033D@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>
Message-ID: <447C096A3E2889439233CDD6DAB29F95ADE313BA@TOSBLRMBX03.TOSHIBA-TSIP.COM>

>what evidence you have that what you do is ineffective?
I tried connecting to some host by executing curl command with --tlsv1.1 and --tlsv1.0 options and am able to connect successfully.

>why you're not using?
>./config no-tls1 no-tls1_1
I have used these options in Makefile but still communication with TLS1.0 and TLS1.1 is working.
Confirmed by checking openssl/opensslconf.h file for OPENSSL_NO_TLS1 and OPENSSL_NO_TLS1_1 macros and macros are generated.

Kindly let me know what could be changed to disable TLS 1.0 and 1.1 at least by changing code in openssl.

-----Original Message-----
From: Hubert Kario [mailto:hkario at redhat.com] 
Sent: Friday, April 12, 2019 4:50 PM
To: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
Cc: openssl-users at openssl.org
Subject: Re: How to disable tls 1.0 and tls 1.1

On Friday, 12 April 2019 06:47:54 CEST Chethan Kumar wrote:
> > there is no "min" version in Client Hello, the version in record 
> > layer is irrelevant and used only for backwards compatibility *NOT* 
> > for negotiation
> Thank you for the information. But have a doubt, then what is the 
> importance of SSL_CTX_set_min_proto_version() and 
> SSL_CTX_set_max_proto_version() introduced in 1.1.X along with SSL_CTX_set_options().

when the minimum set is higher than what the server answers with, the *client* will reject the connection after receiving ServerHello

that is:
when SSL_CTX_set_min_proto_version is set to tls 1.2, SSL_CTX_set_max_proto_version si set to tls 1.3 and the server replies with ServerHello.version of (3, 2) i.e. TLS 1.1 the client will abort the connection
 
> I would like to know how to disable TLSv1.0 and 1.1 using configure 
> option[CONFOPTS] in Makefile.

what evidence you have that what you do is ineffective? 

why you're not using?
./config no-tls1 no-tls1_1

> Thanks in advance,
> Chethan Kumar
> 
> 
> -----Original Message-----
> From: Hubert Kario [mailto:hkario at redhat.com]
> Sent: Thursday, April 11, 2019 7:08 PM
> To: openssl-users at openssl.org
> Cc: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> Subject: Re: How to disable tls 1.0 and tls 1.1
> 
> On Thursday, 11 April 2019 15:25:51 CEST Chethan Kumar wrote:
> 
> > Adding to previous mail,
> > We tried -DSSL_OP_NO_TLSv1   -DSSL_OP_NO_TLSv1_1  along with disabling
> > SSLv2
 and v1 but still client hello is sent using min and max as TLS1.0
> > and TLS1.2.
> 
> 
> there is no "min" version in Client Hello, the version in record layer 
> is irrelevant and used only for backwards compatibility *NOT* for 
> negotiation
> 
> 
> > Any idea what is wrong in our options and what should be used instead.?
> 
> 
> compile an openssl server with TLS 1.1 enabled, run openssl s_server 
> -tls1_1 to enable just TLS 1.1 and see if your production compile can 
> connect
 
> 
> > Thanks in advance,
> > Chethan Kumar
> > 
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > Behalf Of Chethan Kumar Sent: Thursday, April 11, 2019 4:25 PM
> > To: openssl-users at openssl.org
> > Subject: How to disable tls 1.0 and tls 1.1
> > 
> > Dear all,
> > 
> > Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 while 
> > compiling openssl package. I am using 1.0.2n openssl version and 
> > disabled
> > SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and 
> > -DOPENSSL_NO_SSL2.
> > 
> > I also have a doubt on difference between -DSSL_OP_NO_SSLv2,
> > -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2. Can someone please explain 
> > the difference.
> > 
> > Thanks in advance,
> > Chethan Kumar
> > 
> > 
> > The information contained in this e-mail message and in any 
> > attachments/annexure/appendices is confidential to the recipient and 
> > may contain privileged information. If you are not the intended 
> > recipient, please notify the sender and delete the message along 
> > with any attachments/annexure/appendices. You should not disclose, 
> > copy or otherwise use the information contained in the message or 
> > any annexure. Any views expressed in this e-mail are those of the 
> > individual sender except where the sender specifically states them 
> > to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> > Although this transmission and any attachments are believed to be 
> > free of any virus or other defect that might affect any computer 
> > system into which it is received and opened, it is the 
> > responsibility of the recipient to ensure that it is virus free and 
> > no responsibility is accepted by Toshiba Software India Pvt. Ltd, 
> > for any loss or damage arising in any way from its use. The 
> > information contained in this e-mail message and in any 
> > attachments/annexure/appendices is confidential to the recipient and may contain privileged information.
> > If you are not the intended recipient, please notify the sender and 
> > delete the message along with any attachments/annexure/appendices. 
> > You should not disclose, copy or otherwise use the information 
> > contained in the message or any annexure. Any views expressed in 
> > this e-mail are those of the individual sender except where the 
> > sender specifically states them to be the views of Toshiba Software India Pvt. Ltd.
> > (TSIP),Bangalore.
> > 
> > Although this transmission and any attachments are believed to be 
> > free of any virus or other defect that might affect any computer 
> > system into which it is received and opened, it is the 
> > responsibility of the recipient to ensure that it is virus free and 
> > no responsibility is accepted by Toshiba Embedded Software India 
> > Pvt. Ltd, for any loss or damage arising in any way from its use.
> 
> 
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic The 
> information contained in this e-mail message and in any 
> attachments/annexure/appendices is confidential to the recipient and 
> may contain privileged information.
> If you are not the intended recipient, please notify the sender and 
> delete the message along with any attachments/annexure/appendices. You 
> should not disclose, copy or otherwise use the information contained 
> in the message or any annexure. Any views expressed in this e-mail are 
> those of the individual sender except where the sender specifically 
> states them to be the views of Toshiba Software India Pvt. Ltd. 
> (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be free 
> of any virus or other defect that might affect any computer system 
> into which it is received and opened, it is the responsibility of the 
> recipient to ensure that it is virus free and no responsibility is 
> accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or 
> damage arising in any way from its use.


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

From hkario at redhat.com  Fri Apr 12 12:40:46 2019
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 12 Apr 2019 14:40:46 +0200
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95ADE313BA@TOSBLRMBX03.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE313BA@TOSBLRMBX03.TOSHIBA-TSIP.COM>
Message-ID: <2806468.R3HG5iltR7@pintsize.usersys.redhat.com>

On Friday, 12 April 2019 13:54:24 CEST Chethan Kumar wrote:
> >what evidence you have that what you do is ineffective?
> 
> I tried connecting to some host by executing curl command with --tlsv1.1 and
> --tlsv1.0 options and am able to connect successfully.

Please note that curl developers have recently changed the meaning of those 
options, please check if they do what you expect them to do by inspecting the 
curl man page.

see: https://github.com/curl/curl/issues/2918

> >why you're not using?
> >./config no-tls1 no-tls1_1
> 
> I have used these options in Makefile but still communication with TLS1.0
> and TLS1.1 is working.

what you mean by "used them in Makefile", I'm talking about configure script

> Confirmed by checking openssl/opensslconf.h file
> for OPENSSL_NO_TLS1 and OPENSSL_NO_TLS1_1 macros and macros are generated. 
> Kindly let me know what could be changed to disable TLS 1.0 and 1.1 at least
> by changing code in openssl.

macros may still be generated because the API is retained for ABI 
compatibility, do adding `no-tls1-method` and `no-tls1_1-method` produce the 
expected result?
 
> -----Original Message-----
> From: Hubert Kario [mailto:hkario at redhat.com] 
> Sent: Friday, April 12, 2019 4:50 PM
> To: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> Cc: openssl-users at openssl.org
> Subject: Re: How to disable tls 1.0 and tls 1.1
> 
> On Friday, 12 April 2019 06:47:54 CEST Chethan Kumar wrote:
> 
> > > there is no "min" version in Client Hello, the version in record 
> > > layer is irrelevant and used only for backwards compatibility *NOT* 
> > > for negotiation
> > 
> > Thank you for the information. But have a doubt, then what is the 
> > importance of SSL_CTX_set_min_proto_version() and 
> > SSL_CTX_set_max_proto_version() introduced in 1.1.X along with
> > SSL_CTX_set_options().
> 
> when the minimum set is higher than what the server answers with, the
> *client* will reject the connection after receiving ServerHello
 
> that is:
> when SSL_CTX_set_min_proto_version is set to tls 1.2,
> SSL_CTX_set_max_proto_version si set to tls 1.3 and the server replies with
> ServerHello.version of (3, 2) i.e. TLS 1.1 the client will abort the
> connection
 
> 
> > I would like to know how to disable TLSv1.0 and 1.1 using configure 
> > option[CONFOPTS] in Makefile.
> 
> 
> what evidence you have that what you do is ineffective? 
> 
> why you're not using?
> ./config no-tls1 no-tls1_1
> 
> 
> > Thanks in advance,
> > Chethan Kumar
> > 
> > 
> > -----Original Message-----
> > From: Hubert Kario [mailto:hkario at redhat.com]
> > Sent: Thursday, April 11, 2019 7:08 PM
> > To: openssl-users at openssl.org
> > Cc: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> > Subject: Re: How to disable tls 1.0 and tls 1.1
> > 
> > On Thursday, 11 April 2019 15:25:51 CEST Chethan Kumar wrote:
> > 
> > 
> > > Adding to previous mail,
> > > We tried -DSSL_OP_NO_TLSv1   -DSSL_OP_NO_TLSv1_1  along with disabling
> > > SSLv2
> 
>  and v1 but still client hello is sent using min and max as TLS1.0
> 
> > > and TLS1.2.
> > 
> > 
> > 
> > there is no "min" version in Client Hello, the version in record layer 
> > is irrelevant and used only for backwards compatibility *NOT* for 
> > negotiation
> > 
> > 
> > 
> > > Any idea what is wrong in our options and what should be used instead.?
> > 
> > 
> > 
> > compile an openssl server with TLS 1.1 enabled, run openssl s_server 
> > -tls1_1 to enable just TLS 1.1 and see if your production compile can 
> > connect
> 
>  
> 
> > 
> > 
> > > Thanks in advance,
> > > Chethan Kumar
> > > 
> > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > > Behalf Of Chethan Kumar Sent: Thursday, April 11, 2019 4:25 PM
> > > To: openssl-users at openssl.org
> > > Subject: How to disable tls 1.0 and tls 1.1
> > > 
> > > Dear all,
> > > 
> > > Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 while 
> > > compiling openssl package. I am using 1.0.2n openssl version and 
> > > disabled
> > > SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and 
> > > -DOPENSSL_NO_SSL2.
> > > 
> > > I also have a doubt on difference between -DSSL_OP_NO_SSLv2,
> > > -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2. Can someone please explain 
> > > the difference.
> > > 
> > > Thanks in advance,
> > > Chethan Kumar
> > > 
> > > 
> > > The information contained in this e-mail message and in any 
> > > attachments/annexure/appendices is confidential to the recipient and 
> > > may contain privileged information. If you are not the intended 
> > > recipient, please notify the sender and delete the message along 
> > > with any attachments/annexure/appendices. You should not disclose, 
> > > copy or otherwise use the information contained in the message or 
> > > any annexure. Any views expressed in this e-mail are those of the 
> > > individual sender except where the sender specifically states them 
> > > to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> > > Although this transmission and any attachments are believed to be 
> > > free of any virus or other defect that might affect any computer 
> > > system into which it is received and opened, it is the 
> > > responsibility of the recipient to ensure that it is virus free and 
> > > no responsibility is accepted by Toshiba Software India Pvt. Ltd, 
> > > for any loss or damage arising in any way from its use. The 
> > > information contained in this e-mail message and in any 
> > > attachments/annexure/appendices is confidential to the recipient and may
> > > contain privileged information.
 If you are not the intended recipient,
> > > please notify the sender and delete the message along with any
> > > attachments/annexure/appendices. You should not disclose, copy or
> > > otherwise use the information
> > > contained in the message or any annexure. Any views expressed in 
> > > this e-mail are those of the individual sender except where the 
> > > sender specifically states them to be the views of Toshiba Software
> > > India Pvt. Ltd.
 (TSIP),Bangalore.
> > > 
> > > Although this transmission and any attachments are believed to be 
> > > free of any virus or other defect that might affect any computer 
> > > system into which it is received and opened, it is the 
> > > responsibility of the recipient to ensure that it is virus free and 
> > > no responsibility is accepted by Toshiba Embedded Software India 
> > > Pvt. Ltd, for any loss or damage arising in any way from its use.
> > 
> > 
> > 
> > 
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic The 
> > information contained in this e-mail message and in any 
> > attachments/annexure/appendices is confidential to the recipient and 
> > may contain privileged information.
> > If you are not the intended recipient, please notify the sender and 
> > delete the message along with any attachments/annexure/appendices. You 
> > should not disclose, copy or otherwise use the information contained 
> > in the message or any annexure. Any views expressed in this e-mail are 
> > those of the individual sender except where the sender specifically 
> > states them to be the views of Toshiba Software India Pvt. Ltd. 
> > (TSIP),Bangalore.
> > 
> > Although this transmission and any attachments are believed to be free 
> > of any virus or other defect that might affect any computer system 
> > into which it is received and opened, it is the responsibility of the 
> > recipient to ensure that it is virus free and no responsibility is 
> > accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or 
> > damage arising in any way from its use.
> 
> 
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
> The information contained in this e-mail message and in any
> attachments/annexure/appendices is confidential to the 
> recipient and may contain privileged information. 
> If you are not the intended recipient, please notify the
> sender and delete the message along with any 
> attachments/annexure/appendices. You should not disclose,
> copy or otherwise use the information contained in the
> message or any annexure. Any views expressed in this e-mail 
> are those of the individual sender except where the sender 
> specifically states them to be the views of 
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be
> free of any virus or other defect that might affect any computer 
> system into which it is received and opened, it is the responsibility
> of the recipient to ensure that it is virus free and no responsibility 
> is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
> damage arising in any way from its use.


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190412/bc303044/attachment.sig>

From matt at openssl.org  Fri Apr 12 13:16:00 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Apr 2019 14:16:00 +0100
Subject: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
In-Reply-To: <DM6PR07MB46507E7E2D2026087EAAF918F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
References: <DM6PR07MB4650E3F5C694C10F37140339F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
 <bf113179-e246-a690-d723-59d95f04c076@openssl.org>
 <DM6PR07MB46507E7E2D2026087EAAF918F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
Message-ID: <38746820-5c2d-abf1-d2f0-364c1a90b601@openssl.org>



On 11/04/2019 17:43, John Unsworth wrote:
> Attached. This is with the debug build.

Hmmm, this seems to suggest failures in SHA3 and X448 code. Perhaps assembler
issues?

Try compiling with "no-asm" as a Configure option. That's not really a viable
option for production code but it at least rules assembler issues in or out.

Matt



> 
> John
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
> Sent: 11 April 2019 17:40
> To: openssl-users at openssl.org
> Subject: Re: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
> 
> CAUTION: This email originated from outside of Synchronoss.
> 
> 
> On 11/04/2019 15:20, John Unsworth wrote:
> 
>> test\recipes\30-test_evp.t ...................... Dubious, test 
>> returned 4 (wstat 1024, 0x400)
> 
> Can you tell us the result from :
> 
> nmake TESTS=test_evp V=1 test
> 
> Thanks
> 
> Matt
> 

From Chethan.Kumar at toshiba-tsip.com  Fri Apr 12 13:37:37 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Fri, 12 Apr 2019 13:37:37 +0000
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <2806468.R3HG5iltR7@pintsize.usersys.redhat.com>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE313BA@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <2806468.R3HG5iltR7@pintsize.usersys.redhat.com>
Message-ID: <447C096A3E2889439233CDD6DAB29F95ADE3140B@TOSBLRMBX03.TOSHIBA-TSIP.COM>

>Please note that curl developers have recently changed the meaning of those options, please check if they do what you expect them to do by inspecting the curl man page.
Thanks for the information. I understood it.
I also used openssl s_client to communicate with server using below command.
openssl s_client -connect 172.28.80.66:8080 -tls1_1
It says " unknown option -tls1_1"
Same for -tls1.

And even if I disable TLSv1.2 and execute  
openssl s_client -connect 172.28.80.66:8080 -no_tls1_2
WARNING: can't open config file: /usr/local/ebx/ssl/openssl.cnf
CONNECTED(00000003)
2001716872:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1555075165
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
--- 

>what you mean by "used them in Makefile", I'm talking about configure script
I added these options in Makefile like,
CONFOPTS += linux-ppc -DOPENSSL_NO_SSL3 -DOPENSSL_NO_SSL2 -DSSL_OP_NO_SSLv2 no-tls1 no-tls1_1 no-tls1-method no-tls1_1-method

> do adding `no-tls1-method` and `no-tls1_1-method` produce the expected result?
Yes, even after adding these options it produces the same result.

I am confused what is the problem.
Let me know if there is any other way to disable TLSv1.0 and TLS1.1


Thanks in advance,
Chethan Kumar
-----Original Message-----
From: Hubert Kario [mailto:hkario at redhat.com] 
Sent: Friday, April 12, 2019 6:11 PM
To: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
Cc: openssl-users at openssl.org
Subject: Re: How to disable tls 1.0 and tls 1.1

On Friday, 12 April 2019 13:54:24 CEST Chethan Kumar wrote:
> >what evidence you have that what you do is ineffective?
> 
> I tried connecting to some host by executing curl command with 
> --tlsv1.1 and
> --tlsv1.0 options and am able to connect successfully.

Please note that curl developers have recently changed the meaning of those options, please check if they do what you expect them to do by inspecting the curl man page.

see: https://github.com/curl/curl/issues/2918

> >why you're not using?
> >./config no-tls1 no-tls1_1
> 
> I have used these options in Makefile but still communication with 
> TLS1.0 and TLS1.1 is working.

what you mean by "used them in Makefile", I'm talking about configure script

> Confirmed by checking openssl/opensslconf.h file for OPENSSL_NO_TLS1 
> and OPENSSL_NO_TLS1_1 macros and macros are generated.
> Kindly let me know what could be changed to disable TLS 1.0 and 1.1 at 
> least by changing code in openssl.

macros may still be generated because the API is retained for ABI compatibility, do adding `no-tls1-method` and `no-tls1_1-method` produce the expected result?
 
> -----Original Message-----
> From: Hubert Kario [mailto:hkario at redhat.com]
> Sent: Friday, April 12, 2019 4:50 PM
> To: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> Cc: openssl-users at openssl.org
> Subject: Re: How to disable tls 1.0 and tls 1.1
> 
> On Friday, 12 April 2019 06:47:54 CEST Chethan Kumar wrote:
> 
> > > there is no "min" version in Client Hello, the version in record 
> > > layer is irrelevant and used only for backwards compatibility 
> > > *NOT* for negotiation
> > 
> > Thank you for the information. But have a doubt, then what is the 
> > importance of SSL_CTX_set_min_proto_version() and
> > SSL_CTX_set_max_proto_version() introduced in 1.1.X along with 
> > SSL_CTX_set_options().
> 
> when the minimum set is higher than what the server answers with, the
> *client* will reject the connection after receiving ServerHello
 
> that is:
> when SSL_CTX_set_min_proto_version is set to tls 1.2, 
> SSL_CTX_set_max_proto_version si set to tls 1.3 and the server replies 
> with ServerHello.version of (3, 2) i.e. TLS 1.1 the client will abort 
> the connection
 
> 
> > I would like to know how to disable TLSv1.0 and 1.1 using configure 
> > option[CONFOPTS] in Makefile.
> 
> 
> what evidence you have that what you do is ineffective? 
> 
> why you're not using?
> ./config no-tls1 no-tls1_1
> 
> 
> > Thanks in advance,
> > Chethan Kumar
> > 
> > 
> > -----Original Message-----
> > From: Hubert Kario [mailto:hkario at redhat.com]
> > Sent: Thursday, April 11, 2019 7:08 PM
> > To: openssl-users at openssl.org
> > Cc: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> > Subject: Re: How to disable tls 1.0 and tls 1.1
> > 
> > On Thursday, 11 April 2019 15:25:51 CEST Chethan Kumar wrote:
> > 
> > 
> > > Adding to previous mail,
> > > We tried -DSSL_OP_NO_TLSv1   -DSSL_OP_NO_TLSv1_1  along with disabling
> > > SSLv2
> 
>  and v1 but still client hello is sent using min and max as TLS1.0
> 
> > > and TLS1.2.
> > 
> > 
> > 
> > there is no "min" version in Client Hello, the version in record 
> > layer is irrelevant and used only for backwards compatibility *NOT* 
> > for negotiation
> > 
> > 
> > 
> > > Any idea what is wrong in our options and what should be used instead.?
> > 
> > 
> > 
> > compile an openssl server with TLS 1.1 enabled, run openssl s_server
> > -tls1_1 to enable just TLS 1.1 and see if your production compile 
> > can connect
> 
>  
> 
> > 
> > 
> > > Thanks in advance,
> > > Chethan Kumar
> > > 
> > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > > Behalf Of Chethan Kumar Sent: Thursday, April 11, 2019 4:25 PM
> > > To: openssl-users at openssl.org
> > > Subject: How to disable tls 1.0 and tls 1.1
> > > 
> > > Dear all,
> > > 
> > > Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 
> > > while compiling openssl package. I am using 1.0.2n openssl version 
> > > and disabled
> > > SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and 
> > > -DOPENSSL_NO_SSL2.
> > > 
> > > I also have a doubt on difference between -DSSL_OP_NO_SSLv2,
> > > -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2. Can someone please 
> > > explain the difference.
> > > 
> > > Thanks in advance,
> > > Chethan Kumar
> > > 
> > > 
> > > The information contained in this e-mail message and in any 
> > > attachments/annexure/appendices is confidential to the recipient 
> > > and may contain privileged information. If you are not the 
> > > intended recipient, please notify the sender and delete the 
> > > message along with any attachments/annexure/appendices. You should 
> > > not disclose, copy or otherwise use the information contained in 
> > > the message or any annexure. Any views expressed in this e-mail 
> > > are those of the individual sender except where the sender 
> > > specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> > > Although this transmission and any attachments are believed to be 
> > > free of any virus or other defect that might affect any computer 
> > > system into which it is received and opened, it is the 
> > > responsibility of the recipient to ensure that it is virus free 
> > > and no responsibility is accepted by Toshiba Software India Pvt. 
> > > Ltd, for any loss or damage arising in any way from its use. The 
> > > information contained in this e-mail message and in any 
> > > attachments/annexure/appendices is confidential to the recipient 
> > > and may contain privileged information.
 If you are not the intended recipient,
> > > please notify the sender and delete the message along with any 
> > > attachments/annexure/appendices. You should not disclose, copy or 
> > > otherwise use the information contained in the message or any 
> > > annexure. Any views expressed in this e-mail are those of the 
> > > individual sender except where the sender specifically states them 
> > > to be the views of Toshiba Software India Pvt. Ltd.
 (TSIP),Bangalore.
> > > 
> > > Although this transmission and any attachments are believed to be 
> > > free of any virus or other defect that might affect any computer 
> > > system into which it is received and opened, it is the 
> > > responsibility of the recipient to ensure that it is virus free 
> > > and no responsibility is accepted by Toshiba Embedded Software 
> > > India Pvt. Ltd, for any loss or damage arising in any way from its use.
> > 
> > 
> > 
> > 
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic 
> > The information contained in this e-mail message and in any 
> > attachments/annexure/appendices is confidential to the recipient and 
> > may contain privileged information.
> > If you are not the intended recipient, please notify the sender and 
> > delete the message along with any attachments/annexure/appendices. 
> > You should not disclose, copy or otherwise use the information 
> > contained in the message or any annexure. Any views expressed in 
> > this e-mail are those of the individual sender except where the 
> > sender specifically states them to be the views of Toshiba Software India Pvt. Ltd.
> > (TSIP),Bangalore.
> > 
> > Although this transmission and any attachments are believed to be 
> > free of any virus or other defect that might affect any computer 
> > system into which it is received and opened, it is the 
> > responsibility of the recipient to ensure that it is virus free and 
> > no responsibility is accepted by Toshiba Embedded Software India 
> > Pvt. Ltd, for any loss or damage arising in any way from its use.
> 
> 
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic The 
> information contained in this e-mail message and in any 
> attachments/annexure/appendices is confidential to the recipient and 
> may contain privileged information.
> If you are not the intended recipient, please notify the sender and 
> delete the message along with any attachments/annexure/appendices. You 
> should not disclose, copy or otherwise use the information contained 
> in the message or any annexure. Any views expressed in this e-mail are 
> those of the individual sender except where the sender specifically 
> states them to be the views of Toshiba Software India Pvt. Ltd. 
> (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be free 
> of any virus or other defect that might affect any computer system 
> into which it is received and opened, it is the responsibility of the 
> recipient to ensure that it is virus free and no responsibility is 
> accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or 
> damage arising in any way from its use.


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

From hkario at redhat.com  Fri Apr 12 13:49:56 2019
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 12 Apr 2019 15:49:56 +0200
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95ADE3140B@TOSBLRMBX03.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2806468.R3HG5iltR7@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE3140B@TOSBLRMBX03.TOSHIBA-TSIP.COM>
Message-ID: <2011085.P6kfqagWk5@pintsize.usersys.redhat.com>

On Friday, 12 April 2019 15:37:37 CEST Chethan Kumar wrote:
> >Please note that curl developers have recently changed the meaning of those
> >options, please check if they do what you expect them to do by inspecting
> >the curl man page.
> Thanks for the information. I understood it.
> I also used openssl s_client to communicate with server using below
> command.
> openssl s_client -connect 172.28.80.66:8080 -tls1_1
> It says " unknown option -tls1_1"
> Same for -tls1.
> 
> And even if I disable TLSv1.2 and execute  
> openssl s_client -connect 172.28.80.66:8080 -no_tls1_2
> WARNING: can't open config file: /usr/local/ebx/ssl/openssl.cnf
> CONNECTED(00000003)
> 2001716872:error:140790E5:SSL routines:ssl23_write:ssl handshake
> failure:s23_lib.c:177:
 ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 113 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : 0000
>     Session-ID:
>     Session-ID-ctx:
>     Master-Key:
>     Key-Arg   : None
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1555075165
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> --- 

that looks like TLS 1.1 being disabled to me
 
> >what you mean by "used them in Makefile", I'm talking about configure
> >script
> I added these options in Makefile like,
> CONFOPTS += linux-ppc -DOPENSSL_NO_SSL3 -DOPENSSL_NO_SSL2 -DSSL_OP_NO_SSLv2
> no-tls1 no-tls1_1 no-tls1-method no-tls1_1-method
 
> 
> > do adding `no-tls1-method` and `no-tls1_1-method` produce the expected
> > result?
> Yes, even after adding these options it produces the same result.
> 
> I am confused what is the problem.
> Let me know if there is any other way to disable TLSv1.0 and TLS1.1

sorry, I'm not familiar with openssl compilation configuration to say if this 
is expected and correct behaviour

> Thanks in advance,
> Chethan Kumar
> -----Original Message-----
> From: Hubert Kario [mailto:hkario at redhat.com] 
> Sent: Friday, April 12, 2019 6:11 PM
> To: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> Cc: openssl-users at openssl.org
> Subject: Re: How to disable tls 1.0 and tls 1.1
> 
> On Friday, 12 April 2019 13:54:24 CEST Chethan Kumar wrote:
> 
> > >what evidence you have that what you do is ineffective?
> > 
> > 
> > I tried connecting to some host by executing curl command with 
> > --tlsv1.1 and
> > --tlsv1.0 options and am able to connect successfully.
> 
> 
> Please note that curl developers have recently changed the meaning of those
> options, please check if they do what you expect them to do by inspecting
> the curl man page.
 
> see: https://github.com/curl/curl/issues/2918
> 
> 
> > >why you're not using?
> > >./config no-tls1 no-tls1_1
> > 
> > 
> > I have used these options in Makefile but still communication with 
> > TLS1.0 and TLS1.1 is working.
> 
> 
> what you mean by "used them in Makefile", I'm talking about configure
> script
 
> 
> > Confirmed by checking openssl/opensslconf.h file for OPENSSL_NO_TLS1 
> > and OPENSSL_NO_TLS1_1 macros and macros are generated.
> > Kindly let me know what could be changed to disable TLS 1.0 and 1.1 at 
> > least by changing code in openssl.
> 
> 
> macros may still be generated because the API is retained for ABI
> compatibility, do adding `no-tls1-method` and `no-tls1_1-method` produce
> the expected result?
 
> 
> > -----Original Message-----
> > From: Hubert Kario [mailto:hkario at redhat.com]
> > Sent: Friday, April 12, 2019 4:50 PM
> > To: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> > Cc: openssl-users at openssl.org
> > Subject: Re: How to disable tls 1.0 and tls 1.1
> > 
> > On Friday, 12 April 2019 06:47:54 CEST Chethan Kumar wrote:
> > 
> > 
> > > > there is no "min" version in Client Hello, the version in record 
> > > > layer is irrelevant and used only for backwards compatibility 
> > > > *NOT* for negotiation
> > > 
> > > 
> > > Thank you for the information. But have a doubt, then what is the 
> > > importance of SSL_CTX_set_min_proto_version() and
> > > SSL_CTX_set_max_proto_version() introduced in 1.1.X along with 
> > > SSL_CTX_set_options().
> > 
> > 
> > when the minimum set is higher than what the server answers with, the
> > *client* will reject the connection after receiving ServerHello
> 
>  
> 
> > that is:
> > when SSL_CTX_set_min_proto_version is set to tls 1.2, 
> > SSL_CTX_set_max_proto_version si set to tls 1.3 and the server replies 
> > with ServerHello.version of (3, 2) i.e. TLS 1.1 the client will abort 
> > the connection
> 
>  
> 
> > 
> > 
> > > I would like to know how to disable TLSv1.0 and 1.1 using configure 
> > > option[CONFOPTS] in Makefile.
> > 
> > 
> > 
> > what evidence you have that what you do is ineffective? 
> > 
> > why you're not using?
> > ./config no-tls1 no-tls1_1
> > 
> > 
> > 
> > > Thanks in advance,
> > > Chethan Kumar
> > > 
> > > 
> > > -----Original Message-----
> > > From: Hubert Kario [mailto:hkario at redhat.com]
> > > Sent: Thursday, April 11, 2019 7:08 PM
> > > To: openssl-users at openssl.org
> > > Cc: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>
> > > Subject: Re: How to disable tls 1.0 and tls 1.1
> > > 
> > > On Thursday, 11 April 2019 15:25:51 CEST Chethan Kumar wrote:
> > > 
> > > 
> > > 
> > > > Adding to previous mail,
> > > > We tried -DSSL_OP_NO_TLSv1   -DSSL_OP_NO_TLSv1_1  along with
> > > > disabling
> > > > SSLv2
> > 
> > 
> > 
> >  and v1 but still client hello is sent using min and max as TLS1.0
> > 
> > 
> > 
> > > > and TLS1.2.
> > > 
> > > 
> > > 
> > > 
> > > there is no "min" version in Client Hello, the version in record 
> > > layer is irrelevant and used only for backwards compatibility *NOT* 
> > > for negotiation
> > > 
> > > 
> > > 
> > > 
> > > > Any idea what is wrong in our options and what should be used
> > > > instead.?
> > > 
> > > 
> > > 
> > > 
> > > compile an openssl server with TLS 1.1 enabled, run openssl s_server
> > > -tls1_1 to enable just TLS 1.1 and see if your production compile 
> > > can connect
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > > 
> > > 
> > > 
> > > > Thanks in advance,
> > > > Chethan Kumar
> > > > 
> > > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> > > > Behalf Of Chethan Kumar Sent: Thursday, April 11, 2019 4:25 PM
> > > > To: openssl-users at openssl.org
> > > > Subject: How to disable tls 1.0 and tls 1.1
> > > > 
> > > > Dear all,
> > > > 
> > > > Kindly help me out in knowing how to disable TLS1.0 and TLS1.1 
> > > > while compiling openssl package. I am using 1.0.2n openssl version 
> > > > and disabled
> > > > SSLv1 and v2 using -DSSL_OP_NO_SSLv2, -DOPENSSL_NO_SSL3 and 
> > > > -DOPENSSL_NO_SSL2.
> > > > 
> > > > I also have a doubt on difference between -DSSL_OP_NO_SSLv2,
> > > > -DOPENSSL_NO_SSL3 and -DOPENSSL_NO_SSL2. Can someone please 
> > > > explain the difference.
> > > > 
> > > > Thanks in advance,
> > > > Chethan Kumar
> > > > 
> > > > 
> > > > The information contained in this e-mail message and in any 
> > > > attachments/annexure/appendices is confidential to the recipient 
> > > > and may contain privileged information. If you are not the 
> > > > intended recipient, please notify the sender and delete the 
> > > > message along with any attachments/annexure/appendices. You should 
> > > > not disclose, copy or otherwise use the information contained in 
> > > > the message or any annexure. Any views expressed in this e-mail 
> > > > are those of the individual sender except where the sender 
> > > > specifically states them to be the views of Toshiba Software India
> > > > Pvt. Ltd. (TSIP),Bangalore.
 Although this transmission and any
> > > > attachments are believed to be free of any virus or other defect that
> > > > might affect any computer system into which it is received and
> > > > opened, it is the
> > > > responsibility of the recipient to ensure that it is virus free 
> > > > and no responsibility is accepted by Toshiba Software India Pvt. 
> > > > Ltd, for any loss or damage arising in any way from its use. The 
> > > > information contained in this e-mail message and in any 
> > > > attachments/annexure/appendices is confidential to the recipient 
> > > > and may contain privileged information.
> 
>  If you are not the intended recipient,
> 
> > > > please notify the sender and delete the message along with any 
> > > > attachments/annexure/appendices. You should not disclose, copy or 
> > > > otherwise use the information contained in the message or any 
> > > > annexure. Any views expressed in this e-mail are those of the 
> > > > individual sender except where the sender specifically states them 
> > > > to be the views of Toshiba Software India Pvt. Ltd.
> 
>  (TSIP),Bangalore.
> 
> > > > 
> > > > Although this transmission and any attachments are believed to be 
> > > > free of any virus or other defect that might affect any computer 
> > > > system into which it is received and opened, it is the 
> > > > responsibility of the recipient to ensure that it is virus free 
> > > > and no responsibility is accepted by Toshiba Embedded Software 
> > > > India Pvt. Ltd, for any loss or damage arising in any way from its
> > > > use.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > --
> > > Regards,
> > > Hubert Kario
> > > Senior Quality Engineer, QE BaseOS Security team
> > > Web: www.cz.redhat.com
> > > Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic 
> > > The information contained in this e-mail message and in any 
> > > attachments/annexure/appendices is confidential to the recipient and 
> > > may contain privileged information.
> > > If you are not the intended recipient, please notify the sender and 
> > > delete the message along with any attachments/annexure/appendices. 
> > > You should not disclose, copy or otherwise use the information 
> > > contained in the message or any annexure. Any views expressed in 
> > > this e-mail are those of the individual sender except where the 
> > > sender specifically states them to be the views of Toshiba Software
> > > India Pvt. Ltd.
 (TSIP),Bangalore.
> > > 
> > > Although this transmission and any attachments are believed to be 
> > > free of any virus or other defect that might affect any computer 
> > > system into which it is received and opened, it is the 
> > > responsibility of the recipient to ensure that it is virus free and 
> > > no responsibility is accepted by Toshiba Embedded Software India 
> > > Pvt. Ltd, for any loss or damage arising in any way from its use.
> > 
> > 
> > 
> > 
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic The 
> > information contained in this e-mail message and in any 
> > attachments/annexure/appendices is confidential to the recipient and 
> > may contain privileged information.
> > If you are not the intended recipient, please notify the sender and 
> > delete the message along with any attachments/annexure/appendices. You 
> > should not disclose, copy or otherwise use the information contained 
> > in the message or any annexure. Any views expressed in this e-mail are 
> > those of the individual sender except where the sender specifically 
> > states them to be the views of Toshiba Software India Pvt. Ltd. 
> > (TSIP),Bangalore.
> > 
> > Although this transmission and any attachments are believed to be free 
> > of any virus or other defect that might affect any computer system 
> > into which it is received and opened, it is the responsibility of the 
> > recipient to ensure that it is virus free and no responsibility is 
> > accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or 
> > damage arising in any way from its use.
> 
> 
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
> The information contained in this e-mail message and in any
> attachments/annexure/appendices is confidential to the 
> recipient and may contain privileged information. 
> If you are not the intended recipient, please notify the
> sender and delete the message along with any 
> attachments/annexure/appendices. You should not disclose,
> copy or otherwise use the information contained in the
> message or any annexure. Any views expressed in this e-mail 
> are those of the individual sender except where the sender 
> specifically states them to be the views of 
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be
> free of any virus or other defect that might affect any computer 
> system into which it is received and opened, it is the responsibility
> of the recipient to ensure that it is virus free and no responsibility 
> is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
> damage arising in any way from its use.


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190412/17254d5d/attachment.sig>

From matt at openssl.org  Fri Apr 12 13:57:55 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Apr 2019 14:57:55 +0100
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95ADE3140B@TOSBLRMBX03.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE313BA@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <2806468.R3HG5iltR7@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE3140B@TOSBLRMBX03.TOSHIBA-TSIP.COM>
Message-ID: <c5b9e136-8f42-b153-45e2-d28d3a7c11f3@openssl.org>



On 12/04/2019 14:37, Chethan Kumar wrote:
>> Please note that curl developers have recently changed the meaning of those options, please check if they do what you expect them to do by inspecting the curl man page.
> Thanks for the information. I understood it.
> I also used openssl s_client to communicate with server using below command.
> openssl s_client -connect 172.28.80.66:8080 -tls1_1
> It says " unknown option -tls1_1"
> Same for -tls1.

If s_client doesn't recognise the -tls1_1 and -tls1 options then this mean that
TLSv1.1 and TLSv1.0 have been disabled.

> 
> And even if I disable TLSv1.2 and execute  
> openssl s_client -connect 172.28.80.66:8080 -no_tls1_2
> WARNING: can't open config file: /usr/local/ebx/ssl/openssl.cnf
> CONNECTED(00000003)
> 2001716872:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

So you attempt a connection and ask s_client to disable TLSv1.2 at runtime.
You've already asked it to disable TLSv1.1 and TLSv1.0 at compile time. Since
SSLv3 is also compiled out by default there are no protocol versions left so the
expected result will be a handshake failure - which is exactly what you've got.

>> what you mean by "used them in Makefile", I'm talking about configure script
> I added these options in Makefile like,
> CONFOPTS += linux-ppc -DOPENSSL_NO_SSL3 -DOPENSSL_NO_SSL2 -DSSL_OP_NO_SSLv2 no-tls1 no-tls1_1 no-tls1-method no-tls1_1-method

*Don't edit the Makefile*. You only need to pass options to Configure.

> 
>> do adding `no-tls1-method` and `no-tls1_1-method` produce the expected result?
> Yes, even after adding these options it produces the same result.

The result above means you have disabled TLSv1.1 and TLSv1.0 - which was your
objective IIUC.


> 
> I am confused what is the problem.
> Let me know if there is any other way to disable TLSv1.0 and TLS1.1

It sounds like you already did it.

Matt


From Chethan.Kumar at toshiba-tsip.com  Fri Apr 12 14:50:44 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Fri, 12 Apr 2019 14:50:44 +0000
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <c5b9e136-8f42-b153-45e2-d28d3a7c11f3@openssl.org>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE313BA@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <2806468.R3HG5iltR7@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE3140B@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <c5b9e136-8f42-b153-45e2-d28d3a7c11f3@openssl.org>
Message-ID: <447C096A3E2889439233CDD6DAB29F95ADE31449@TOSBLRMBX03.TOSHIBA-TSIP.COM>

Thank to both Hubert Kario and Matt Caswell for your valuable information.
This group has helped a lot in gaining many insights on openssl  for newbie like me.

I was wrong with my understanding.
But i executed below command to communicate with TLS1.2 when only TLS1.0 and 1.1 was disabled,
Even it got failed to execute by saying "unknown option -tls1_2".
Any reason for that.?

Thanks in advance,
Chethan Kumar

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
Sent: Friday, April 12, 2019 7:28 PM
To: openssl-users at openssl.org
Subject: Re: How to disable tls 1.0 and tls 1.1



On 12/04/2019 14:37, Chethan Kumar wrote:
>> Please note that curl developers have recently changed the meaning of those options, please check if they do what you expect them to do by inspecting the curl man page.
> Thanks for the information. I understood it.
> I also used openssl s_client to communicate with server using below command.
> openssl s_client -connect 172.28.80.66:8080 -tls1_1 It says " unknown 
> option -tls1_1"
> Same for -tls1.

If s_client doesn't recognise the -tls1_1 and -tls1 options then this mean that
TLSv1.1 and TLSv1.0 have been disabled.

> 
> And even if I disable TLSv1.2 and execute openssl s_client -connect 
> 172.28.80.66:8080 -no_tls1_2
> WARNING: can't open config file: /usr/local/ebx/ssl/openssl.cnf
> CONNECTED(00000003)
> 2001716872:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

So you attempt a connection and ask s_client to disable TLSv1.2 at runtime.
You've already asked it to disable TLSv1.1 and TLSv1.0 at compile time. Since
SSLv3 is also compiled out by default there are no protocol versions left so the expected result will be a handshake failure - which is exactly what you've got.

>> what you mean by "used them in Makefile", I'm talking about configure 
>> script
> I added these options in Makefile like, CONFOPTS += linux-ppc 
> -DOPENSSL_NO_SSL3 -DOPENSSL_NO_SSL2 -DSSL_OP_NO_SSLv2 no-tls1 
> no-tls1_1 no-tls1-method no-tls1_1-method

*Don't edit the Makefile*. You only need to pass options to Configure.

> 
>> do adding `no-tls1-method` and `no-tls1_1-method` produce the expected result?
> Yes, even after adding these options it produces the same result.

The result above means you have disabled TLSv1.1 and TLSv1.0 - which was your objective IIUC.


> 
> I am confused what is the problem.
> Let me know if there is any other way to disable TLSv1.0 and TLS1.1

It sounds like you already did it.

Matt

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

From matt at openssl.org  Fri Apr 12 15:51:15 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Apr 2019 16:51:15 +0100
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95ADE31449@TOSBLRMBX03.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE313BA@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <2806468.R3HG5iltR7@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE3140B@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <c5b9e136-8f42-b153-45e2-d28d3a7c11f3@openssl.org>
 <447C096A3E2889439233CDD6DAB29F95ADE31449@TOSBLRMBX03.TOSHIBA-TSIP.COM>
Message-ID: <fd1d5af7-4505-b93f-e0d5-e99e768d1fce@openssl.org>



On 12/04/2019 15:50, Chethan Kumar wrote:
> Thank to both Hubert Kario and Matt Caswell for your valuable information.
> This group has helped a lot in gaining many insights on openssl  for newbie like me.
> 
> I was wrong with my understanding.
> But i executed below command to communicate with TLS1.2 when only TLS1.0 and 1.1 was disabled,
> Even it got failed to execute by saying "unknown option -tls1_2".
> Any reason for that.?

Ah! My apologies - I've just now realised that you are using OpenSSL 1.0.2 (and
going back to your original post I see that you did actually say that). Sorry
for misleading you.

OpenSSL 1.0.2 works differently to later versions in this regards and quite
inconsistently. You can disable SSLv2 and SSLv3 at compile time (SSLv2 is
disabled by default) using the no-ssl2 and no-ssl3 options.

If you want to disable TLSv1.0 and TLSv1.1 then you should do so at run time.
Use the SSL_OP_NO_TLSv1 and SSL_OP_NO_TLSv1_1 options to the
SSL_CTX_set_options() or SSL_set_options() functions.

Matt

> 
> Thanks in advance,
> Chethan Kumar
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
> Sent: Friday, April 12, 2019 7:28 PM
> To: openssl-users at openssl.org
> Subject: Re: How to disable tls 1.0 and tls 1.1
> 
> 
> 
> On 12/04/2019 14:37, Chethan Kumar wrote:
>>> Please note that curl developers have recently changed the meaning of those options, please check if they do what you expect them to do by inspecting the curl man page.
>> Thanks for the information. I understood it.
>> I also used openssl s_client to communicate with server using below command.
>> openssl s_client -connect 172.28.80.66:8080 -tls1_1 It says " unknown 
>> option -tls1_1"
>> Same for -tls1.
> 
> If s_client doesn't recognise the -tls1_1 and -tls1 options then this mean that
> TLSv1.1 and TLSv1.0 have been disabled.
> 
>>
>> And even if I disable TLSv1.2 and execute openssl s_client -connect 
>> 172.28.80.66:8080 -no_tls1_2
>> WARNING: can't open config file: /usr/local/ebx/ssl/openssl.cnf
>> CONNECTED(00000003)
>> 2001716872:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
> 
> So you attempt a connection and ask s_client to disable TLSv1.2 at runtime.
> You've already asked it to disable TLSv1.1 and TLSv1.0 at compile time. Since
> SSLv3 is also compiled out by default there are no protocol versions left so the expected result will be a handshake failure - which is exactly what you've got.
> 
>>> what you mean by "used them in Makefile", I'm talking about configure 
>>> script
>> I added these options in Makefile like, CONFOPTS += linux-ppc 
>> -DOPENSSL_NO_SSL3 -DOPENSSL_NO_SSL2 -DSSL_OP_NO_SSLv2 no-tls1 
>> no-tls1_1 no-tls1-method no-tls1_1-method
> 
> *Don't edit the Makefile*. You only need to pass options to Configure.
> 
>>
>>> do adding `no-tls1-method` and `no-tls1_1-method` produce the expected result?
>> Yes, even after adding these options it produces the same result.
> 
> The result above means you have disabled TLSv1.1 and TLSv1.0 - which was your objective IIUC.
> 
> 
>>
>> I am confused what is the problem.
>> Let me know if there is any other way to disable TLSv1.0 and TLS1.1
> 
> It sounds like you already did it.
> 
> Matt
> 
> The information contained in this e-mail message and in any
> attachments/annexure/appendices is confidential to the 
> recipient and may contain privileged information. 
> If you are not the intended recipient, please notify the
> sender and delete the message along with any 
> attachments/annexure/appendices. You should not disclose,
> copy or otherwise use the information contained in the
> message or any annexure. Any views expressed in this e-mail 
> are those of the individual sender except where the sender 
> specifically states them to be the views of 
> Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be
> free of any virus or other defect that might affect any computer 
> system into which it is received and opened, it is the responsibility
> of the recipient to ensure that it is virus free and no responsibility 
> is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
> damage arising in any way from its use.
> 

From haba713 at gmail.com  Fri Apr 12 17:20:47 2019
From: haba713 at gmail.com (Harri T.)
Date: Fri, 12 Apr 2019 20:20:47 +0300
Subject: =?UTF-8?Q?SSL=5fconnect:error_in_SSLv3/TLS_write_client_hello_?=
 =?UTF-8?B?4oaSIHdyaXRlOmVycm5vPTA=?=
Message-ID: <59acb0df-f7b6-d76e-7081-acaccf790ce1@gmail.com>

Hi!

I'm trying to get LDAP STARTTLS working. What does "SSL_connect:error in SSLv3/TLS write client hello ? write:errno=0" mean?

Harri

root at ldap2:~# echo | openssl s_client -connect ldap2.mydomain.com:389 -showcerts -state -CAfile /etc/ssl/certs/ldap2_cacert.pem 
CONNECTED(00000003)
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:error in SSLv3/TLS write client hello
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1555084061
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

From John.Unsworth at synchronoss.com  Sat Apr 13 14:28:02 2019
From: John.Unsworth at synchronoss.com (John Unsworth)
Date: Sat, 13 Apr 2019 14:28:02 +0000
Subject: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
In-Reply-To: <38746820-5c2d-abf1-d2f0-364c1a90b601@openssl.org>
References: <DM6PR07MB4650E3F5C694C10F37140339F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
 <bf113179-e246-a690-d723-59d95f04c076@openssl.org>
 <DM6PR07MB46507E7E2D2026087EAAF918F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
 <38746820-5c2d-abf1-d2f0-364c1a90b601@openssl.org>
Message-ID: <DM6PR07MB4650270A58A30912074EA915F5290@DM6PR07MB4650.namprd07.prod.outlook.com>

Seems OK. nmake TESTS=test_evp V=1 test results attached.

C:\Downloads\OpenSSL\openssl-1.1.1b>perl Configure VC-WIN64A no-asm no-shared --prefix=C:\Downloads\OpenSSL\openssl-1.1.1b\static
nmake install
nmake test
All tests successful.
Files=155, Tests=1163, 163 wallclock secs ( 0.73 usr +  0.19 sys =  0.92 CPU)
Result: PASS

Regards,
John

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: 12 April 2019 14:16
To: openssl-users at openssl.org
Subject: Re: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013

CAUTION: This email originated from outside of Synchronoss.


On 11/04/2019 17:43, John Unsworth wrote:
> Attached. This is with the debug build.

Hmmm, this seems to suggest failures in SHA3 and X448 code. Perhaps assembler issues?

Try compiling with "no-asm" as a Configure option. That's not really a viable option for production code but it at least rules assembler issues in or out.

Matt



>
> John
>
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of 
> Matt Caswell
> Sent: 11 April 2019 17:40
> To: openssl-users at openssl.org
> Subject: Re: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
>
> CAUTION: This email originated from outside of Synchronoss.
>
>
> On 11/04/2019 15:20, John Unsworth wrote:
>
>> test\recipes\30-test_evp.t ...................... Dubious, test 
>> returned 4 (wstat 1024, 0x400)
>
> Can you tell us the result from :
>
> nmake TESTS=test_evp V=1 test
>
> Thanks
>
> Matt
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: no-asm.txt
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190413/ae77a1e0/attachment-0001.txt>

From Chethan.Kumar at toshiba-tsip.com  Mon Apr 15 06:13:43 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Mon, 15 Apr 2019 06:13:43 +0000
Subject: How to disable tls 1.0 and tls 1.1
In-Reply-To: <fd1d5af7-4505-b93f-e0d5-e99e768d1fce@openssl.org>
References: <447C096A3E2889439233CDD6DAB29F95ADE2C110@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2056075.iMr3OEZ87E@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE313BA@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <2806468.R3HG5iltR7@pintsize.usersys.redhat.com>
 <447C096A3E2889439233CDD6DAB29F95ADE3140B@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <c5b9e136-8f42-b153-45e2-d28d3a7c11f3@openssl.org>
 <447C096A3E2889439233CDD6DAB29F95ADE31449@TOSBLRMBX03.TOSHIBA-TSIP.COM>
 <fd1d5af7-4505-b93f-e0d5-e99e768d1fce@openssl.org>
Message-ID: <447C096A3E2889439233CDD6DAB29F95ADE31590@TOSBLRMBX03.TOSHIBA-TSIP.COM>

>>If you want to disable TLSv1.0 and TLSv1.1 then you should do so at run time.
>>Use the SSL_OP_NO_TLSv1 and SSL_OP_NO_TLSv1_1 options to the
>>SSL_CTX_set_options() or SSL_set_options() functions.
Since we have many applications using openssl services, it is difficult to implement this in all applications.

I need to find a single point in openssl source code[If not in Makefile] to disable TLSv1.0 and TLS1.1 for both server and client communications.

Thanks in advance,
Chethan

-----Original Message-----
From: Matt Caswell [mailto:matt at openssl.org] 
Sent: Friday, April 12, 2019 9:21 PM
To: Chethan Kumar <Chethan.Kumar at toshiba-tsip.com>; openssl-users at openssl.org
Subject: Re: How to disable tls 1.0 and tls 1.1



On 12/04/2019 15:50, Chethan Kumar wrote:
> Thank to both Hubert Kario and Matt Caswell for your valuable information.
> This group has helped a lot in gaining many insights on openssl  for newbie like me.
> 
> I was wrong with my understanding.
> But i executed below command to communicate with TLS1.2 when only 
> TLS1.0 and 1.1 was disabled, Even it got failed to execute by saying "unknown option -tls1_2".
> Any reason for that.?

Ah! My apologies - I've just now realised that you are using OpenSSL 1.0.2 (and going back to your original post I see that you did actually say that). Sorry for misleading you.

OpenSSL 1.0.2 works differently to later versions in this regards and quite inconsistently. You can disable SSLv2 and SSLv3 at compile time (SSLv2 is disabled by default) using the no-ssl2 and no-ssl3 options.

If you want to disable TLSv1.0 and TLSv1.1 then you should do so at run time.
Use the SSL_OP_NO_TLSv1 and SSL_OP_NO_TLSv1_1 options to the
SSL_CTX_set_options() or SSL_set_options() functions.

Matt

> 
> Thanks in advance,
> Chethan Kumar
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
> Behalf Of Matt Caswell
> Sent: Friday, April 12, 2019 7:28 PM
> To: openssl-users at openssl.org
> Subject: Re: How to disable tls 1.0 and tls 1.1
> 
> 
> 
> On 12/04/2019 14:37, Chethan Kumar wrote:
>>> Please note that curl developers have recently changed the meaning of those options, please check if they do what you expect them to do by inspecting the curl man page.
>> Thanks for the information. I understood it.
>> I also used openssl s_client to communicate with server using below command.
>> openssl s_client -connect 172.28.80.66:8080 -tls1_1 It says " unknown 
>> option -tls1_1"
>> Same for -tls1.
> 
> If s_client doesn't recognise the -tls1_1 and -tls1 options then this 
> mean that
> TLSv1.1 and TLSv1.0 have been disabled.
> 
>>
>> And even if I disable TLSv1.2 and execute openssl s_client -connect
>> 172.28.80.66:8080 -no_tls1_2
>> WARNING: can't open config file: /usr/local/ebx/ssl/openssl.cnf
>> CONNECTED(00000003)
>> 2001716872:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
> 
> So you attempt a connection and ask s_client to disable TLSv1.2 at runtime.
> You've already asked it to disable TLSv1.1 and TLSv1.0 at compile 
> time. Since
> SSLv3 is also compiled out by default there are no protocol versions left so the expected result will be a handshake failure - which is exactly what you've got.
> 
>>> what you mean by "used them in Makefile", I'm talking about 
>>> configure script
>> I added these options in Makefile like, CONFOPTS += linux-ppc
>> -DOPENSSL_NO_SSL3 -DOPENSSL_NO_SSL2 -DSSL_OP_NO_SSLv2 no-tls1
>> no-tls1_1 no-tls1-method no-tls1_1-method
> 
> *Don't edit the Makefile*. You only need to pass options to Configure.
> 
>>
>>> do adding `no-tls1-method` and `no-tls1_1-method` produce the expected result?
>> Yes, even after adding these options it produces the same result.
> 
> The result above means you have disabled TLSv1.1 and TLSv1.0 - which was your objective IIUC.
> 
> 
>>
>> I am confused what is the problem.
>> Let me know if there is any other way to disable TLSv1.0 and TLS1.1
> 
> It sounds like you already did it.
> 
> Matt
> 
> The information contained in this e-mail message and in any 
> attachments/annexure/appendices is confidential to the recipient and 
> may contain privileged information.
> If you are not the intended recipient, please notify the sender and 
> delete the message along with any attachments/annexure/appendices. You 
> should not disclose, copy or otherwise use the information contained 
> in the message or any annexure. Any views expressed in this e-mail are 
> those of the individual sender except where the sender specifically 
> states them to be the views of Toshiba Software India Pvt. Ltd. 
> (TSIP),Bangalore.
> 
> Although this transmission and any attachments are believed to be free 
> of any virus or other defect that might affect any computer system 
> into which it is received and opened, it is the responsibility of the 
> recipient to ensure that it is virus free and no responsibility is 
> accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or 
> damage arising in any way from its use.
> 
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

From beldmit at gmail.com  Mon Apr 15 07:39:52 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 15 Apr 2019 10:39:52 +0300
Subject: Blinding implementation in OpenSSL
Message-ID: <CADqLbzL34rCmSCHZxi5fzuK_gh_-k085-aRHf=kbTWHJXPPkyg@mail.gmail.com>

Hello,

Could you please explain how blinding works in OpenSSL?

EC_KEY structure seems to have an unblinded private key structure and
blinded X, Y, Z- coordinates of the public key when blinding is in use. But
if I understand correctly, he idea of blinding is protecting the private
key from extracting from memory/swap/etc? Am I wrong?

Many thanks in advance!

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

From tim.j.culhane at gmail.com  Mon Apr 15 08:35:28 2019
From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com)
Date: Mon, 15 Apr 2019 09:35:28 +0100
Subject: Best way of preventing denial of service attacks by way of secure
 client-initiated renegotiation
Message-ID: <001e01d4f366$2e3a8d70$8aafa850$@gmail.com>

Hi all,

A customer of ours was recently running security checks against our mail
server.  To do this they were running the testssl.sh script available at:

https://testssl.sh/

The test tool reports a potential DoS thread as a result of client-initiated
secure renegotiation as shown from the following line from the test tool's
output:


 Secure Client-Initiated Renegotiation     VULNERABLE (NOT
ok), potential DoS threat

I have also reproduced  their findings in-house.

Our mail server is using version 1.0.2g of openssl  and  the client openssl
version was 1.0.2j.

In the testssl.sh script  it connects to the ssl port using TLS1.2  and the
legacy_renegotiation option.

When I do a similar  test in my test environment  I  get results like the
below:

 Issue  a connect request, pause for 1 second and then Send 'R'  to start a
renegotiation:

(echo -n; sleep 1; echo R) | openssl s_client -CAfile NightlyBuild-CA.cert
-crlf -tls1_2 -legacy_renegotiation -connect <hostname>:465

Output is as follows:



CONNECTED(00000003)
---
Certificate chain
 0 s:/C=ie/CN=something/CN=devimpala13.es.cpth.ie
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIC0DCCAjmgAwIBAgIBATANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJBVTET
...
-----END CERTIFICATE-----
subject=/C=ie/CN=something/CN=devimpala13.es.cpth.ie
issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SH
A256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA
+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SH
A256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA
+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1297 bytes and written 445 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID:
A1E559EAFC571033874C52C715E8CE3452751FB80AD843F4E051E77664F20FFE
    Session-ID-ctx: 
    Master-Key:
BE06E684D71B9B3349DBB057C433BB0C0C44717EF2157EAA912A896F43DF8E6E912A69B8258E
C9031CF2219F0F031C1B
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 61 3a da 77 02 6c 7e 26-c1 98 84 ae 26 21 8f 1d
a:.w.l~&....&!..
...
    Start Time: 1555315404
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
220 devimpala13.es.cpth.ie ESMTP Service ready
RENEGOTIATING
depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify return:1
depth=0 C = ie, CN = something, CN = devimpala13.es.cpth.ie
verify return:1
DONE

So, as you can see the  initial connection is successful.   The
renegotiation  begins and  it returns:

verify return:1

I'm not sure if this means  renegotiation has failed?  Either way the
connection remains open.  Presumably if a client issued a large number of
renegotiations like this the server could become overwhelmed.

Note that I got the same results if I remove the -legacy_renegotiation
option, so I don't think  this has any impact?

So, I suppose I firstly need to know if the results from testssl.sh and from
my own investigations point to a potential security risk by way of a DoS
attack?

If so, what is the best way to prevent this.
>From what I've read online it isn't possible to disable client-initiated
secure renegotiation in openssl.
Indeed, it could be argued that there are circumstances when it is perfectly
valid for a client to renegotiate a connection  especially if it is a
long-running connection.

The only  way I could find of limiting such an attack was to track the
number of renegotiation requests over a time and if we get a high number  in
a short period  then close the connection.
I believe this can be done  in a callback function  set up via a call to:

SSL_CTX_set_info_callback


So, is the above information correct or is there a better way of preventing
this sort of attack.  Do we really need to allow a limited form of
client-based secure renegotiation?

If preventing an attack by way of monitoring the number of renegotiations
over time is the only good approach, do you have any code examples in C as
to how to implement this?

Many thanks,

Tim



From swamy.j-s at in.abb.com  Mon Apr 15 11:25:55 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Mon, 15 Apr 2019 11:25:55 +0000
Subject: CRYPTO_LOCK_X509_STORE in OpenSSL 1.1.0
Message-ID: <HE1PR0602MB3643284E9D697E9E25A4CA1D962B0@HE1PR0602MB3643.eurprd06.prod.outlook.com>

Hi All,


I updated openssl from 1.0.2n to 1.1.0g recently and facing some errors in building my application because many functions and structures are opaque now in 1.1.0g. Errors am getting are as below :


error: ?CRYPTO_LOCK_X509_STORE? undeclared (first use in this function); did you mean ?CRYPTO_EX_INDEX_X509_STORE??
             CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
                           ^~~~~~~~~~~~~~~~~~~~~~
                           CRYPTO_EX_INDEX_X509_STORE

 warning: implicit declaration of function ?CRYPTO_w_lock?; did you mean ?CRYPTO_zalloc?? [-Wimplicit-function-declaration]
             CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
             ^~~~~~~~~~~~~
             CRYPTO_zalloc


So what is the alternate option available for "CRYPTO_LOCK_X509_STORE" and "CRYPTO_w_lock" in openssl 1.1.0g ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190415/51d78424/attachment-0001.html>

From matt at openssl.org  Mon Apr 15 11:52:26 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Apr 2019 12:52:26 +0100
Subject: CRYPTO_LOCK_X509_STORE in OpenSSL 1.1.0
In-Reply-To: <HE1PR0602MB3643284E9D697E9E25A4CA1D962B0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB3643284E9D697E9E25A4CA1D962B0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <197e0720-259b-3a9d-2045-b423031e3b05@openssl.org>



On 15/04/2019 12:25, Swamy J-S wrote:
> Hi All,
> 
> 
> I updated openssl from 1.0.2n to 1.1.0g recently and facing some errors in
> building my application because many functions and structures are opaque now in
> 1.1.0g. Errors am getting are as below :
> 
> 
> error: ?CRYPTO_LOCK_X509_STORE? undeclared (first use in this function); did you
> mean ?CRYPTO_EX_INDEX_X509_STORE??
> ???????????? CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
> ?????????????????????????? ^~~~~~~~~~~~~~~~~~~~~~
> ?????????????????????????? CRYPTO_EX_INDEX_X509_STORE
> 
> ?warning: implicit declaration of function ?CRYPTO_w_lock?; did you mean
> ?CRYPTO_zalloc?? [-Wimplicit-function-declaration]
> ???????????? CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
> ???????????? ^~~~~~~~~~~~~
> ???????????? CRYPTO_zalloc
> 
> So what is the alternate option available for "CRYPTO_LOCK_X509_STORE" and
> "CRYPTO_w_lock" in openssl 1.1.0g ?
> 

What are you attempting to do that requires you to acquire this lock? The API
functions should acquire and release the lock automatically where appropriate.

Matt

From matt at openssl.org  Mon Apr 15 12:44:00 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Apr 2019 13:44:00 +0100
Subject: Best way of preventing denial of service attacks by way of secure
 client-initiated renegotiation
In-Reply-To: <001e01d4f366$2e3a8d70$8aafa850$@gmail.com>
References: <001e01d4f366$2e3a8d70$8aafa850$@gmail.com>
Message-ID: <a4d1f34e-8921-b262-3396-8ee0000871d9@openssl.org>



On 15/04/2019 09:35, tim.j.culhane at gmail.com wrote:
> I'm not sure if this means  renegotiation has failed?  Either way the
> connection remains open.  Presumably if a client issued a large number of
> renegotiations like this the server could become overwhelmed.

No - renegotiation was successful.

> Note that I got the same results if I remove the -legacy_renegotiation
> option, so I don't think  this has any impact?

The legacy_renegotiation option does something different to what you think it
does. This option allows "insecure" renegotiation as opposed to the later (and
default) "secure" renegotiation. This dates back to 2009 when a flaw in the TLS
protocol for renegotiation was discovered.

> 
> So, I suppose I firstly need to know if the results from testssl.sh and from
> my own investigations point to a potential security risk by way of a DoS
> attack?

Over the years there have been many attacks against renegotiation. They've all
been fixed, however since this is a common attack vector and many applications
don't need this feature it is often recommended that it is disabled.


> If so, what is the best way to prevent this.

The best way is to upgrade to a recent version of OpenSSL and use the
SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and above).

If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is
undocumented and unfortunately this method is no longer possible in OpenSSL
1.1.0+ due to the opacity changes.

You can mark a particular SSL object (call it "s") so that it should not do
renegotiation like this:

s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;


> From what I've read online it isn't possible to disable client-initiated
> secure renegotiation in openssl.
> Indeed, it could be argued that there are circumstances when it is perfectly
> valid for a client to renegotiate a connection  especially if it is a
> long-running connection.
> 
> The only  way I could find of limiting such an attack was to track the
> number of renegotiation requests over a time and if we get a high number  in
> a short period  then close the connection.
> I believe this can be done  in a callback function  set up via a call to:
> 
> SSL_CTX_set_info_callback

I'd recommend against this approach. A number of applications took this route
due to a lack of a good alternative. However it can have unexpected consequences
if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 (where a number of
legitimate interactions happen post-handshake that can be mistaken for
renegotiations).

Matt

From tmraz at redhat.com  Mon Apr 15 12:58:40 2019
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 15 Apr 2019 14:58:40 +0200
Subject: Blinding implementation in OpenSSL
In-Reply-To: <CADqLbzL34rCmSCHZxi5fzuK_gh_-k085-aRHf=kbTWHJXPPkyg@mail.gmail.com>
References: <CADqLbzL34rCmSCHZxi5fzuK_gh_-k085-aRHf=kbTWHJXPPkyg@mail.gmail.com>
Message-ID: <3fe905140764d96198fd957e87d829be737d1072.camel@redhat.com>

On Mon, 2019-04-15 at 10:39 +0300, Dmitry Belyavsky wrote:
> Hello,
> 
> Could you please explain how blinding works in OpenSSL?
> 
> EC_KEY structure seems to have an unblinded private key structure and
> blinded X, Y, Z- coordinates of the public key when blinding is in
> use. But if I understand correctly, he idea of blinding is protecting
> the private key from extracting from memory/swap/etc? Am I wrong?

No, blinding is done during the private key operations to "randomize"
the computations so timing and other side channels do not leak the
private key. The private key itself is not modified.

-- 
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 tim.j.culhane at gmail.com  Mon Apr 15 13:41:26 2019
From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com)
Date: Mon, 15 Apr 2019 14:41:26 +0100
Subject: Best way of preventing denial of service attacks by way of secure
 client-initiated renegotiation
In-Reply-To: <a4d1f34e-8921-b262-3396-8ee0000871d9@openssl.org>
References: <001e01d4f366$2e3a8d70$8aafa850$@gmail.com>
 <a4d1f34e-8921-b262-3396-8ee0000871d9@openssl.org>
Message-ID: <000501d4f390$eca937a0$c5fba6e0$@gmail.com>

Hi Matt,

Many thanks for your informative reply.

So it seems the best approach is to  upgrade to a version of OpenSSL  supporting the SSL_OP_NO_RENGOTIATION option.

If this option is enabled will it  still allow server-initiated secure  renegotiations if TLS 1.3 is being used?

The docs suggests that only  client side renegotiation requests are disabled in TLS 1.3.

Tim


-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: Monday 15 April 2019 13:44
To: openssl-users at openssl.org
Subject: Re: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation



On 15/04/2019 09:35, tim.j.culhane at gmail.com wrote:
> I'm not sure if this means  renegotiation has failed?  Either way the 
> connection remains open.  Presumably if a client issued a large number 
> of renegotiations like this the server could become overwhelmed.

No - renegotiation was successful.

> Note that I got the same results if I remove the -legacy_renegotiation 
> option, so I don't think  this has any impact?

The legacy_renegotiation option does something different to what you think it does. This option allows "insecure" renegotiation as opposed to the later (and
default) "secure" renegotiation. This dates back to 2009 when a flaw in the TLS protocol for renegotiation was discovered.

> 
> So, I suppose I firstly need to know if the results from testssl.sh 
> and from my own investigations point to a potential security risk by 
> way of a DoS attack?

Over the years there have been many attacks against renegotiation. They've all been fixed, however since this is a common attack vector and many applications don't need this feature it is often recommended that it is disabled.


> If so, what is the best way to prevent this.

The best way is to upgrade to a recent version of OpenSSL and use the SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and above).

If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is undocumented and unfortunately this method is no longer possible in OpenSSL 1.1.0+ due to the opacity changes.

You can mark a particular SSL object (call it "s") so that it should not do renegotiation like this:

s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;


> From what I've read online it isn't possible to disable 
> client-initiated secure renegotiation in openssl.
> Indeed, it could be argued that there are circumstances when it is 
> perfectly valid for a client to renegotiate a connection  especially 
> if it is a long-running connection.
> 
> The only  way I could find of limiting such an attack was to track the 
> number of renegotiation requests over a time and if we get a high 
> number  in a short period  then close the connection.
> I believe this can be done  in a callback function  set up via a call to:
> 
> SSL_CTX_set_info_callback

I'd recommend against this approach. A number of applications took this route due to a lack of a good alternative. However it can have unexpected consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 (where a number of legitimate interactions happen post-handshake that can be mistaken for renegotiations).

Matt


From matt at openssl.org  Mon Apr 15 13:45:00 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Apr 2019 14:45:00 +0100
Subject: Best way of preventing denial of service attacks by way of secure
 client-initiated renegotiation
In-Reply-To: <000501d4f390$eca937a0$c5fba6e0$@gmail.com>
References: <001e01d4f366$2e3a8d70$8aafa850$@gmail.com>
 <a4d1f34e-8921-b262-3396-8ee0000871d9@openssl.org>
 <000501d4f390$eca937a0$c5fba6e0$@gmail.com>
Message-ID: <8571125b-f725-76ad-3b2e-e16d965eeb9b@openssl.org>



On 15/04/2019 14:41, tim.j.culhane at gmail.com wrote:
> Hi Matt,
> 
> Many thanks for your informative reply.
> 
> So it seems the best approach is to  upgrade to a version of OpenSSL  supporting the SSL_OP_NO_RENGOTIATION option.
> 
> If this option is enabled will it  still allow server-initiated secure  renegotiations if TLS 1.3 is being used?
> 
> The docs suggests that only  client side renegotiation requests are disabled in TLS 1.3.

Renegotiation does not exist as a concept in TLSv1.3 so this option has no
impact in TLSv1.3.

Matt


> 
> Tim
> 
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
> Sent: Monday 15 April 2019 13:44
> To: openssl-users at openssl.org
> Subject: Re: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation
> 
> 
> 
> On 15/04/2019 09:35, tim.j.culhane at gmail.com wrote:
>> I'm not sure if this means  renegotiation has failed?  Either way the 
>> connection remains open.  Presumably if a client issued a large number 
>> of renegotiations like this the server could become overwhelmed.
> 
> No - renegotiation was successful.
> 
>> Note that I got the same results if I remove the -legacy_renegotiation 
>> option, so I don't think  this has any impact?
> 
> The legacy_renegotiation option does something different to what you think it does. This option allows "insecure" renegotiation as opposed to the later (and
> default) "secure" renegotiation. This dates back to 2009 when a flaw in the TLS protocol for renegotiation was discovered.
> 
>>
>> So, I suppose I firstly need to know if the results from testssl.sh 
>> and from my own investigations point to a potential security risk by 
>> way of a DoS attack?
> 
> Over the years there have been many attacks against renegotiation. They've all been fixed, however since this is a common attack vector and many applications don't need this feature it is often recommended that it is disabled.
> 
> 
>> If so, what is the best way to prevent this.
> 
> The best way is to upgrade to a recent version of OpenSSL and use the SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and above).
> 
> If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is undocumented and unfortunately this method is no longer possible in OpenSSL 1.1.0+ due to the opacity changes.
> 
> You can mark a particular SSL object (call it "s") so that it should not do renegotiation like this:
> 
> s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
> 
> 
>> From what I've read online it isn't possible to disable 
>> client-initiated secure renegotiation in openssl.
>> Indeed, it could be argued that there are circumstances when it is 
>> perfectly valid for a client to renegotiate a connection  especially 
>> if it is a long-running connection.
>>
>> The only  way I could find of limiting such an attack was to track the 
>> number of renegotiation requests over a time and if we get a high 
>> number  in a short period  then close the connection.
>> I believe this can be done  in a callback function  set up via a call to:
>>
>> SSL_CTX_set_info_callback
> 
> I'd recommend against this approach. A number of applications took this route due to a lack of a good alternative. However it can have unexpected consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 (where a number of legitimate interactions happen post-handshake that can be mistaken for renegotiations).
> 
> Matt
> 

From bbrumley at gmail.com  Mon Apr 15 13:56:45 2019
From: bbrumley at gmail.com (Billy Brumley)
Date: Mon, 15 Apr 2019 16:56:45 +0300
Subject: Blinding implementation in OpenSSL
In-Reply-To: <3fe905140764d96198fd957e87d829be737d1072.camel@redhat.com>
References: <CADqLbzL34rCmSCHZxi5fzuK_gh_-k085-aRHf=kbTWHJXPPkyg@mail.gmail.com>
 <3fe905140764d96198fd957e87d829be737d1072.camel@redhat.com>
Message-ID: <CAFeDd5YWGDjJt93U77nBtYA21grZM6OeMwKc32vafgYFJdML=Q@mail.gmail.com>

> > Could you please explain how blinding works in OpenSSL?
> >
> > EC_KEY structure seems to have an unblinded private key structure and
> > blinded X, Y, Z- coordinates of the public key when blinding is in
> > use. But if I understand correctly, he idea of blinding is protecting
> > the private key from extracting from memory/swap/etc? Am I wrong?
>
> No, blinding is done during the private key operations to "randomize"
> the computations so timing and other side channels do not leak the
> private key. The private key itself is not modified.

Dmitry is correct in that coordinate blinding and scalar blinding are
different things. The question seems to be why doesn't OpenSSL do
coordinate blinding. (Hoping I'm not interpreting too much.)

BBB

From tim.j.culhane at gmail.com  Mon Apr 15 13:58:22 2019
From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com)
Date: Mon, 15 Apr 2019 14:58:22 +0100
Subject: Best way of preventing denial of service attacks by way of secure
 client-initiated renegotiation
In-Reply-To: <8571125b-f725-76ad-3b2e-e16d965eeb9b@openssl.org>
References: <001e01d4f366$2e3a8d70$8aafa850$@gmail.com>
 <a4d1f34e-8921-b262-3396-8ee0000871d9@openssl.org>
 <000501d4f390$eca937a0$c5fba6e0$@gmail.com>
 <8571125b-f725-76ad-3b2e-e16d965eeb9b@openssl.org>
Message-ID: <000601d4f393$4a080a50$de181ef0$@gmail.com>

Ok, great thanks.

-----Original Message-----
From: Matt Caswell <matt at openssl.org> 
Sent: Monday 15 April 2019 14:45
To: tim.j.culhane at gmail.com; openssl-users at openssl.org
Subject: Re: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation



On 15/04/2019 14:41, tim.j.culhane at gmail.com wrote:
> Hi Matt,
> 
> Many thanks for your informative reply.
> 
> So it seems the best approach is to  upgrade to a version of OpenSSL  supporting the SSL_OP_NO_RENGOTIATION option.
> 
> If this option is enabled will it  still allow server-initiated secure  renegotiations if TLS 1.3 is being used?
> 
> The docs suggests that only  client side renegotiation requests are disabled in TLS 1.3.

Renegotiation does not exist as a concept in TLSv1.3 so this option has no impact in TLSv1.3.

Matt


> 
> Tim
> 
> 
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of 
> Matt Caswell
> Sent: Monday 15 April 2019 13:44
> To: openssl-users at openssl.org
> Subject: Re: Best way of preventing denial of service attacks by way 
> of secure client-initiated renegotiation
> 
> 
> 
> On 15/04/2019 09:35, tim.j.culhane at gmail.com wrote:
>> I'm not sure if this means  renegotiation has failed?  Either way the 
>> connection remains open.  Presumably if a client issued a large 
>> number of renegotiations like this the server could become overwhelmed.
> 
> No - renegotiation was successful.
> 
>> Note that I got the same results if I remove the 
>> -legacy_renegotiation option, so I don't think  this has any impact?
> 
> The legacy_renegotiation option does something different to what you 
> think it does. This option allows "insecure" renegotiation as opposed 
> to the later (and
> default) "secure" renegotiation. This dates back to 2009 when a flaw in the TLS protocol for renegotiation was discovered.
> 
>>
>> So, I suppose I firstly need to know if the results from testssl.sh 
>> and from my own investigations point to a potential security risk by 
>> way of a DoS attack?
> 
> Over the years there have been many attacks against renegotiation. They've all been fixed, however since this is a common attack vector and many applications don't need this feature it is often recommended that it is disabled.
> 
> 
>> If so, what is the best way to prevent this.
> 
> The best way is to upgrade to a recent version of OpenSSL and use the SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and above).
> 
> If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is undocumented and unfortunately this method is no longer possible in OpenSSL 1.1.0+ due to the opacity changes.
> 
> You can mark a particular SSL object (call it "s") so that it should not do renegotiation like this:
> 
> s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
> 
> 
>> From what I've read online it isn't possible to disable 
>> client-initiated secure renegotiation in openssl.
>> Indeed, it could be argued that there are circumstances when it is 
>> perfectly valid for a client to renegotiate a connection  especially 
>> if it is a long-running connection.
>>
>> The only  way I could find of limiting such an attack was to track 
>> the number of renegotiation requests over a time and if we get a high 
>> number  in a short period  then close the connection.
>> I believe this can be done  in a callback function  set up via a call to:
>>
>> SSL_CTX_set_info_callback
> 
> I'd recommend against this approach. A number of applications took this route due to a lack of a good alternative. However it can have unexpected consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 (where a number of legitimate interactions happen post-handshake that can be mistaken for renegotiations).
> 
> Matt
> 


From bbrumley at gmail.com  Mon Apr 15 13:59:11 2019
From: bbrumley at gmail.com (Billy Brumley)
Date: Mon, 15 Apr 2019 16:59:11 +0300
Subject: Blinding implementation in OpenSSL
In-Reply-To: <CAFeDd5YWGDjJt93U77nBtYA21grZM6OeMwKc32vafgYFJdML=Q@mail.gmail.com>
References: <CADqLbzL34rCmSCHZxi5fzuK_gh_-k085-aRHf=kbTWHJXPPkyg@mail.gmail.com>
 <3fe905140764d96198fd957e87d829be737d1072.camel@redhat.com>
 <CAFeDd5YWGDjJt93U77nBtYA21grZM6OeMwKc32vafgYFJdML=Q@mail.gmail.com>
Message-ID: <CAFeDd5bwDt0TdBS+JXnjB8AmyUcTV6qSXtsnNbKndoK85sxCPA@mail.gmail.com>

("OpenSSL doesn't do" _scalar_ blinding! Coordinate blinding is there.
sorry ...)

From jain61 at gmail.com  Mon Apr 15 21:23:02 2019
From: jain61 at gmail.com (NJ)
Date: Mon, 15 Apr 2019 14:23:02 -0700 (MST)
Subject: URGENT: Parsing DTLS Alerts in OpenSSL
Message-ID: <1555363382875-0.post@n7.nabble.com>

Hi,

I am facing issue while trying to parse the Alert received from client.
I could see the Alert on wireshark  as "Alert(21) Handshake Failure" but
while trying to parse it from below code doesn't work.

I want to parse this error and try to re-initiate the handshake from my
server code. 

ctx_info_callback( const SSL *s, int where, int ret )
{
    const char *str;
    int w;

    if( w & SSL_ST_ACCEPT) // I only have server implemented
         str = "SSL_accept"  

    if( where & SSL_CB_LOOP)
    {
        // printed state string
    }else if (where & SSL_CB_ALERT)
    {
        // printed alert type
    }else if ( where & SSL_CB_EXIT )
    {
        // checked ret type   --> Run time only shows "SSL_accept : error in
SSLv3 read client hello B"
    }
  }

I could not complete SSL_do_handshake (in certain cases like network
connection failure) completed and my server gets stuck in read message.
I am trying to understand what might be causing this issue but meanwhile the
client is keep on re-initializing and sending Alert messages.

Any insight on as why I keep on getting this "read client hello B" message
will be helpful. I am using non-blocking sockets so based on documentation
it is correct behavior and for most of the cases I see the sever completes
handshake after certain tries and gets out of this loop.

Only for few cases it gets stuck like when the network connection is lost
but I think if the network connection re-initializes I should be able to
recover it if I could parse these Alerts ?

In order to re-initialize connection I am completely resetting all CTX,SSL,
and socket objects so there is no stale SSL object which might be causing
issues. 

Thanks,
NJ




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

From John.Unsworth at synchronoss.com  Tue Apr 16 08:20:51 2019
From: John.Unsworth at synchronoss.com (John Unsworth)
Date: Tue, 16 Apr 2019 08:20:51 +0000
Subject: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
In-Reply-To: <DM6PR07MB4650270A58A30912074EA915F5290@DM6PR07MB4650.namprd07.prod.outlook.com>
References: <DM6PR07MB4650E3F5C694C10F37140339F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
 <bf113179-e246-a690-d723-59d95f04c076@openssl.org>
 <DM6PR07MB46507E7E2D2026087EAAF918F52F0@DM6PR07MB4650.namprd07.prod.outlook.com>
 <38746820-5c2d-abf1-d2f0-364c1a90b601@openssl.org>
 <DM6PR07MB4650270A58A30912074EA915F5290@DM6PR07MB4650.namprd07.prod.outlook.com>
Message-ID: <DM6PR07MB465068EC0CCA1FAED85711B2F5240@DM6PR07MB4650.namprd07.prod.outlook.com>

Good news. I upgraded nasm to the latest for win64 and everything now works OK.

nasm-2.14.02-win64.zip

C:\Downloads\OpenSSL\openssl-1.1.1b>nasm -v
NASM version 2.14.02 compiled on Dec 26 2018

C:\Downloads\OpenSSL\openssl-1.1.1b>perl Configure VC-WIN64A no-shared --prefix=C:\Downloads\OpenSSL\openssl-1.1.1b\static

C:\Downloads\OpenSSL\openssl-1.1.1b>nmake install

C:\Downloads\OpenSSL\openssl-1.1.1b>nmake test
All tests successful.
Files=155, Tests=1163, 103 wallclock secs ( 0.55 usr +  0.27 sys =  0.81 CPU)
Result: PASS

C:\Downloads\OpenSSL\openssl-1.1.1b>nmake TESTS=test_evp V=1 test
All tests successful.
Files=1, Tests=9,  1 wallclock secs ( 0.02 usr +  0.00 sys =  0.02 CPU)
Result: PASS

Regards,
John

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of John Unsworth
Sent: 13 April 2019 15:28
To: openssl-users at openssl.org
Subject: RE: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013

CAUTION: This email originated from outside of Synchronoss.


Seems OK. nmake TESTS=test_evp V=1 test results attached.

C:\Downloads\OpenSSL\openssl-1.1.1b>perl Configure VC-WIN64A no-asm no-shared --prefix=C:\Downloads\OpenSSL\openssl-1.1.1b\static
nmake install
nmake test
All tests successful.
Files=155, Tests=1163, 163 wallclock secs ( 0.73 usr +  0.19 sys =  0.92 CPU)
Result: PASS

Regards,
John

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell
Sent: 12 April 2019 14:16
To: openssl-users at openssl.org
Subject: Re: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013

CAUTION: This email originated from outside of Synchronoss.


On 11/04/2019 17:43, John Unsworth wrote:
> Attached. This is with the debug build.

Hmmm, this seems to suggest failures in SHA3 and X448 code. Perhaps assembler issues?

Try compiling with "no-asm" as a Configure option. That's not really a viable option for production code but it at least rules assembler issues in or out.

Matt



>
> John
>
> -----Original Message-----
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of 
> Matt Caswell
> Sent: 11 April 2019 17:40
> To: openssl-users at openssl.org
> Subject: Re: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
>
> CAUTION: This email originated from outside of Synchronoss.
>
>
> On 11/04/2019 15:20, John Unsworth wrote:
>
>> test\recipes\30-test_evp.t ...................... Dubious, test 
>> returned 4 (wstat 1024, 0x400)
>
> Can you tell us the result from :
>
> nmake TESTS=test_evp V=1 test
>
> Thanks
>
> Matt
>

From chitrang.srivastava at gmail.com  Tue Apr 16 12:23:51 2019
From: chitrang.srivastava at gmail.com (Chitrang Srivastava)
Date: Tue, 16 Apr 2019 17:53:51 +0530
Subject: rand interface while upgrading openssl
Message-ID: <CANPP3o3FyNZAxyTERNwgG2OUDP8TXr4_-BbNp3q82_XuJQnQ_g@mail.gmail.com>

Hi,

I am trying to upgrade openssl for my embedded OS platform. The one we
currently use is pretty old i.e. *OpenSSL  0.9.6a * , but porting to
Openssl 1.1.1b works fine.

I need suggestion regarding random number interface , earlier we were
using  RAND_METHOD.
Can I still use the same mechanism? Because I see new code *rand* folder
contains OS  specific implementation of

rand_pool_acquire_entropy
rand_pool_add_nonce_data
rand_pool_add_additional_data

As I understand , above function also needs to be ported?
Any document to start with porting random number to any platform.

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

From haba713 at gmail.com  Tue Apr 16 14:40:15 2019
From: haba713 at gmail.com (Harri T.)
Date: Tue, 16 Apr 2019 17:40:15 +0300
Subject: =?UTF-8?Q?Re:_SSL=5fconnect:error_in_SSLv3/TLS_write_client_hello_?=
 =?UTF-8?B?4oaSIHdyaXRlOmVycm5vPTA=?=
In-Reply-To: <59acb0df-f7b6-d76e-7081-acaccf790ce1@gmail.com>
References: <59acb0df-f7b6-d76e-7081-acaccf790ce1@gmail.com>
Message-ID: <ada99e4d-6f61-1c13-8434-398526f89e20@gmail.com>

Hi all,

The problem was an expired self-generated CA certificate. Now everything 
works fine.

Br,

Harri

On 12.04.2019 20:20, Harri T. wrote:
> Hi!
> 
> I'm trying to get LDAP STARTTLS working. What does "SSL_connect:error in SSLv3/TLS write client hello ? write:errno=0" mean?
> 
> Harri
> 
> root at ldap2:~# echo | openssl s_client -connect ldap2.mydomain.com:389 -showcerts -state -CAfile /etc/ssl/certs/ldap2_cacert.pem
> CONNECTED(00000003)
> SSL_connect:before SSL initialization
> SSL_connect:SSLv3/TLS write client hello
> SSL_connect:error in SSLv3/TLS write client hello
> write:errno=0
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 176 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>      Protocol  : TLSv1.2
>      Cipher    : 0000
>      Session-ID:
>      Session-ID-ctx:
>      Master-Key:
>      PSK identity: None
>      PSK identity hint: None
>      SRP username: None
>      Start Time: 1555084061
>      Timeout   : 7200 (sec)
>      Verify return code: 0 (ok)
>      Extended master secret: no
> 


From rsalz at akamai.com  Tue Apr 16 18:34:38 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 16 Apr 2019 18:34:38 +0000
Subject: Travis fixes?
Message-ID: <9ABA28DF-EB4A-4EF6-ACF2-FE8F145F67A3@akamai.com>

Is anyone looking at the failing CI builds?  It?s been a few days now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190416/b2f3f2fd/attachment.html>

From Michael.Wojcik at microfocus.com  Tue Apr 16 19:38:41 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 16 Apr 2019 19:38:41 +0000
Subject: rand interface while upgrading openssl
In-Reply-To: <CANPP3o3FyNZAxyTERNwgG2OUDP8TXr4_-BbNp3q82_XuJQnQ_g@mail.gmail.com>
References: <CANPP3o3FyNZAxyTERNwgG2OUDP8TXr4_-BbNp3q82_XuJQnQ_g@mail.gmail.com>
Message-ID: <BYAPR18MB2918F8740B53791657DF5F8AF9240@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Chitrang Srivastava
> Sent: Tuesday, April 16, 2019 08:24

> I need suggestion regarding random number interface , earlier we were using  RAND_METHOD.

That's a mechanism for telling OpenSSL what mechanism to use for its cryptographically-strong pseudorandom number generator (CPRNG).

> Can I still use the same mechanism? Because I see new code rand folder contains OS specific
> implementation of
>
> rand_pool_acquire_entropy
> rand_pool_add_nonce_data
> rand_pool_add_additional_data

That's part of OpenSSL's mechanism for getting entropy for the CPRNG. The CPRNG needs this, but they are not the same thing.

> As I understand , above function also needs to be ported?

I believe you'll need some implementation of them, but I haven't poked around this corner of the OpenSSL 1.1 sources.

> Any document to start with porting random number to any platform.

The CPRNG seeding mechanism is cryptographically sensitive, and should not be implemented by a non-expert. What does your existing implementation do to provide entropy for the OpenSSL CPRNG? If the answer is "nothing" (or something that's not adequately opaque to an attacker), then your product has seriously flawed security. An attacker who can guess the entropy for the CPRNG pool can break your encryption.

It will also be platform-specific (though some mechanisms will exist on multiple platforms), so there can't be much guidance on doing it for "any platform".

The literature on seeding CPRNGs is fairly extensive. It's often a challenge for embedded applications, particularly SOC-based ones which may not have much in the way of internal noise sources such as clock skew. Some CPUs have entropy sources, such as Intel's RDRAND; if you trust them (and in an embedded application you may not have much choice) you can use that.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


From girishbangaram at gmail.com  Wed Apr 17 06:50:33 2019
From: girishbangaram at gmail.com (girish kumar)
Date: Wed, 17 Apr 2019 12:20:33 +0530
Subject: Test data for the known Openssl CVEs
Message-ID: <CAODwuHrKheLk7mx+=WOtNdNO4B9o3y+xExJvkrfjoQoPZBoT6g@mail.gmail.com>

Hi All,
I am trying to build a regression suite for the known vulnerabilities
published by OpenSSL. For some of the CVEs, I am facing issues to generate
test data.

Is there anywhere test data available for the known CVEs for re-use.

Any help would be appreciated.

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

From chitrang.srivastava at gmail.com  Wed Apr 17 10:54:11 2019
From: chitrang.srivastava at gmail.com (Chitrang Srivastava)
Date: Wed, 17 Apr 2019 16:24:11 +0530
Subject: rand interface while upgrading openssl
In-Reply-To: <BYAPR18MB2918F8740B53791657DF5F8AF9240@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <CANPP3o3FyNZAxyTERNwgG2OUDP8TXr4_-BbNp3q82_XuJQnQ_g@mail.gmail.com>
 <BYAPR18MB2918F8740B53791657DF5F8AF9240@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <CANPP3o1f9E6SGqt_Roy3zsxXpJQe6SiAF8duSNK9xxcMQUCSLQ@mail.gmail.com>

Thanks Michael,

I am using *ssleay_rand_add* function which was present in earlier version
of openssl
https://code.woboq.org/crypto/openssl/crypto/rand/md_rand.c.html#ssleay_rand_add

I don't find this file or function in latest version of openssl.
As I understood recommended way is to use engine method but on embedded
system we compile everything in a single elf binary.
No concept of dynamic shared object or engine , so i defined
OPENSSL_NO_ENGINE to compile engine thing out.

Is there any default random number like md_rand.c in this version of
openssl.
For entropy we will be providing SHA1/SHA2 of a mix of CPU clock and
various other thing(serial #, mac, ) to seed.

-Thanks,

On Wed, Apr 17, 2019 at 1:23 AM Michael Wojcik <
Michael.Wojcik at microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Chitrang Srivastava
> > Sent: Tuesday, April 16, 2019 08:24
>
> > I need suggestion regarding random number interface , earlier we were
> using  RAND_METHOD.
>
> That's a mechanism for telling OpenSSL what mechanism to use for its
> cryptographically-strong pseudorandom number generator (CPRNG).
>
> > Can I still use the same mechanism? Because I see new code rand folder
> contains OS specific
> > implementation of
> >
> > rand_pool_acquire_entropy
> > rand_pool_add_nonce_data
> > rand_pool_add_additional_data
>
> That's part of OpenSSL's mechanism for getting entropy for the CPRNG. The
> CPRNG needs this, but they are not the same thing.
>
> > As I understand , above function also needs to be ported?
>
> I believe you'll need some implementation of them, but I haven't poked
> around this corner of the OpenSSL 1.1 sources.
>
> > Any document to start with porting random number to any platform.
>
> The CPRNG seeding mechanism is cryptographically sensitive, and should not
> be implemented by a non-expert. What does your existing implementation do
> to provide entropy for the OpenSSL CPRNG? If the answer is "nothing" (or
> something that's not adequately opaque to an attacker), then your product
> has seriously flawed security. An attacker who can guess the entropy for
> the CPRNG pool can break your encryption.
>
> It will also be platform-specific (though some mechanisms will exist on
> multiple platforms), so there can't be much guidance on doing it for "any
> platform".
>
> The literature on seeding CPRNGs is fairly extensive. It's often a
> challenge for embedded applications, particularly SOC-based ones which may
> not have much in the way of internal noise sources such as clock skew. Some
> CPUs have entropy sources, such as Intel's RDRAND; if you trust them (and
> in an embedded application you may not have much choice) you can use that.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190417/c5b14fa9/attachment.html>

From guidovranken at gmail.com  Wed Apr 17 18:36:46 2019
From: guidovranken at gmail.com (Guido Vranken)
Date: Wed, 17 Apr 2019 20:36:46 +0200
Subject: Regarding the use of EVP_aes_256_cbc_hmac_sha256, EVP_rc4_hmac_md5
 and AES_encrypt
Message-ID: <CAO5O-E+-7FaNz00GpNqTS2vbuwwgW9Qk6DVDzufUNZVPB7n=jA@mail.gmail.com>

First question:

How should AAD data be supplied to ciphers like
EVP_aes_256_cbc_hmac_sha256() and EVP_rc4_hmac_md5()?

If I understand correctly, these are AEAD ciphers (the
EVP_CIPH_FLAG_AEAD_CIPHER flag is set), so it should be possible to provide
AAD data?

The following seems to work for AEAD ciphers generally but crashes with the
ciphers I just mentioned:

EVP_EncryptUpdate(ctx, NULL, &len, aad, aad_len))

I call this after key and IV setting and before ciphertext input, in fact
exactly like described here for GCM AEAD ciphers:
https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption#Authenticated_Encryption_using_GCM_mode

Am I doing something wrong?

Second question:

The comments around AES_decrypt() and AES_encrypt() in
crypto/aes/aes_core.c state: "in and out can overlap".
Does this only apply to the pure C version of AES, or to any or all
assembly implementations as well?

Thanks

Guido
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190417/0641a70c/attachment-0001.html>

From jerrylui803 at gmail.com  Wed Apr 17 19:36:06 2019
From: jerrylui803 at gmail.com (Jerry Lui)
Date: Wed, 17 Apr 2019 15:36:06 -0400
Subject: ChaCha20 (without Poly1305) block counter
Message-ID: <CAGvkZ-sy0U9XUQHPCOJXojAiEuOkdrAGp1-naqUMJaVsEUn8GA@mail.gmail.com>

Hi,

I am trying to use ChaCha20 (without Poly1305)

>From RFC 7539:
One of the inputs to ChaCha20 is:
"A 32-bit initial counter."

However I cannot find the function to set this. where should I input this?

Thanks,
Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190417/92d21756/attachment.html>

From matt at openssl.org  Thu Apr 18 10:06:12 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Apr 2019 11:06:12 +0100
Subject: ChaCha20 (without Poly1305) block counter
In-Reply-To: <CAGvkZ-sy0U9XUQHPCOJXojAiEuOkdrAGp1-naqUMJaVsEUn8GA@mail.gmail.com>
References: <CAGvkZ-sy0U9XUQHPCOJXojAiEuOkdrAGp1-naqUMJaVsEUn8GA@mail.gmail.com>
Message-ID: <68b22df4-db11-f7d9-9bb2-9c12c18a2b73@openssl.org>



On 17/04/2019 20:36, Jerry Lui wrote:
> Hi,
> 
> I am trying to use ChaCha20 (without Poly1305)
> 
> From RFC 7539:
> One of the inputs to ChaCha20 is:
> "A 32-bit initial counter."
> 
> However I cannot find the function to set this. where should I input this?

>From code inspection it looks to me like our documentation is wrong. Our docs say:

  =item EVP_chacha20()

  The ChaCha20 stream cipher. The key length is 256 bits, the IV is 96 bits long.

The IV here is referring to the number of bytes in the IV field that should be
sent to EVP_EncryptInit_ex().

But what is actually implemented is a 128 bit IV with the first 32 bits being
the counter and the next 96 bits being the nonce.

Additionally the counter is in little-endian order. So a counter of 1 is
expressed as 4 bytes: 01000000

I've raised the following PR to correct this:

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

Matt

From matt at openssl.org  Thu Apr 18 10:48:50 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 18 Apr 2019 11:48:50 +0100
Subject: Regarding the use of EVP_aes_256_cbc_hmac_sha256,
 EVP_rc4_hmac_md5 and AES_encrypt
In-Reply-To: <CAO5O-E+-7FaNz00GpNqTS2vbuwwgW9Qk6DVDzufUNZVPB7n=jA@mail.gmail.com>
References: <CAO5O-E+-7FaNz00GpNqTS2vbuwwgW9Qk6DVDzufUNZVPB7n=jA@mail.gmail.com>
Message-ID: <c4896fd8-70ff-34d7-1012-6ef09d35aa07@openssl.org>



On 17/04/2019 19:36, Guido Vranken wrote:
> First question:
> 
> How should AAD data be supplied to ciphers like EVP_aes_256_cbc_hmac_sha256()
> and EVP_rc4_hmac_md5()?
> 
> If I understand correctly, these are AEAD ciphers (the EVP_CIPH_FLAG_AEAD_CIPHER
> flag is set), so it should be possible to provide AAD data?
> 
> The following seems to work for AEAD ciphers generally but crashes with the
> ciphers I just mentioned:
> 
> EVP_EncryptUpdate(ctx, NULL, &len, aad, aad_len))
> 
> I call this after key and IV setting and before ciphertext input, in fact
> exactly like described here for GCM AEAD ciphers:
> https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption#Authenticated_Encryption_using_GCM_mode
> 
> Am I doing something wrong?

The thing to understand about these ciphers is that they are not intended to be
general purpose at all. They are very much specifically designed to work with
TLS. They do not conform to the general AEAD interface that is available for
GCM, CCM, OCB etc.

Instead they use a specific ctrl: EVP_CTRL_AEAD_TLS1_AAD. This takes as an
argument a pointer to the AAD which must be EVP_AEAD_TLS1_AAD_LEN (13) bytes
long and in a defined format.

> 
> Second question:
> 
> The comments around AES_decrypt() and AES_encrypt() in crypto/aes/aes_core.c
> state: "in and out can overlap".
> Does this only apply to the pure C version of AES, or to any or all assembly
> implementations as well?

As a general rule we allow "in place" encryption but not "partially overlapping"
buffers.

Matt


From swamy.j-s at in.abb.com  Fri Apr 19 09:38:27 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Fri, 19 Apr 2019 09:38:27 +0000
Subject: Error in M_ASN1_New_of function in openssl 1.1.0g
Message-ID: <HE1PR0602MB3643D117CFAF03937FBF764796270@HE1PR0602MB3643.eurprd06.prod.outlook.com>

I upgraded openssl from 1.0.2n to 1.1.0g in Linux recently and am getting some errors in code because many of the openssl functions are deprecated in new version. One such function is malloc function which is M_ASN1_New_Malloc(Poll, CertInfo) which was defined in asn1_mac.h

After openssl upgradation, i searched alternate function to "M_ASN1_New_Malloc" and i changed my code as below
DECLARE_ASN1_ALLOC_FUNCTIONS(CertInfo)
CertInfo *Poll = NULL;
Poll = M_ASN1_New_of(CertInfo)

When i build my code am getting error as undefined reference to 'CertInfo_it'.

I don't why its adding "_it" to CertInfo unnecessarily**.


Thanks and Regards,
SWAMY J S

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

From matt at openssl.org  Fri Apr 19 10:05:39 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Apr 2019 11:05:39 +0100
Subject: Error in M_ASN1_New_of function in openssl 1.1.0g
In-Reply-To: <HE1PR0602MB3643D117CFAF03937FBF764796270@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB3643D117CFAF03937FBF764796270@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <16bf49ac-1cb3-73ca-71a1-023968dcfe19@openssl.org>



On 19/04/2019 10:38, Swamy J-S wrote:

> After openssl upgradation, i searched alternate function to "M_ASN1_New_Malloc"
> and i changed my code as below
> 
> DECLARE_ASN1_ALLOC_FUNCTIONS(CertInfo)
> 
> CertInfo *Poll = NULL;
> 
> Poll = M_ASN1_New_of(CertInfo)

How have you declared and implemented the CertInfo structure?

E.g. You might declare it like this:

typedef struct CertInfo_st {
    ASN1_OCTET_STRING *whatever;
} CertInfo;
DECLARE_ASN1_FUNCTIONS(CertInfo)

And then implement it something like this:

ASN1_SEQUENCE(CertInfo) = {
    ASN1_SIMPLE(CertInfo, whatever, ASN1_OCTET_STRING)
} ASN1_SEQUENCE_END(CertInfo)
IMPLEMENT_ASN1_FUNCTIONS(CertInfo)


The DECLARE_ASN1_FUNCTIONS macro also uses the DECLARE_ASN1_ALLOC_FUNCTIONS
macro so there is no need to use it separately.

Then in your code you can do something like this:

CertInfo *Poll = NULL;

Poll = CertInfo_new();


Don't use the M_ASN1_New_of macro at all.

Matt

From beldmit at gmail.com  Sun Apr 21 15:58:53 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Sun, 21 Apr 2019 18:58:53 +0300
Subject: asn1parse genstr question
Message-ID: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>

Hello,

I try to create an extension containing an utf8 string.

When I use a command

openssl asn1parse -genstr "UTF8String:?" -out content

I get a 6-byte file. If I understand correctly, it starts with a 2-byte
header indicating the content length and then contains an encoded letter
'?' I want. But the encoding of it is not UTF8, as the utf8 encoding of a
cyrillic letter is 2 bytes long.

Am I wrong? If the behavior I see is desired one, how can I convert the
result of the encoding to UTF8 using openssl internal API?

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190421/7e92f899/attachment-0001.html>

From openssl-users at dukhovni.org  Mon Apr 22 18:23:02 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 22 Apr 2019 14:23:02 -0400
Subject: asn1parse genstr question
In-Reply-To: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
References: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
Message-ID: <20190422182302.GB87116@straasha.imrryr.org>

On Sun, Apr 21, 2019 at 06:58:53PM +0300, Dmitry Belyavsky wrote:

> When I use a command
> 
> openssl asn1parse -genstr "UTF8String:?" -out content
> 
> I get a 6-byte file. If I understand correctly, it starts with a 2-byte
> header indicating the content length and then contains an encoded letter
> '?' I want. But the encoding of it is not UTF8, as the utf8 encoding of a
> cyrillic letter is 2 bytes long.
> 
> Am I wrong? If the behavior I see is desired one, how can I convert the
> result of the encoding to UTF8 using openssl internal API?

By default the input string is assumed to contain single-byte octets,
which are individually encoded as UTF-8.  This is rarely what you
want if your input is not ASCII.  For actual UTF-8 input, you can
use:

    $ openssl asn1parse -out content -genstr 'FORMAT:UTF8,UTF8String:?? ????! ?? ?? ?????, ??? ????!' # [1]
	0:d=0  hl=2 l=  53 prim: UTF8STRING        :?? ????! ?? ?? ?????, ??? ????!

The "genstr" format is described in, for example:

    https://www.openssl.org/docs/man1.0.2/man3/ASN1_generate_nconf.html

-- 
	Viktor.

[1]. http://www.mnemosyne.ru/homo/galich-6.html

From wiml at omnigroup.com  Mon Apr 22 18:35:43 2019
From: wiml at omnigroup.com (Wim Lewis)
Date: Mon, 22 Apr 2019 11:35:43 -0700
Subject: asn1parse genstr question
In-Reply-To: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
References: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
Message-ID: <0B571057-CAB5-4F45-B241-B0BB0447CAE9@omnigroup.com>


On Apr 21, 2019, at 8:58 AM, Dmitry Belyavsky <beldmit at gmail.com> wrote:
> openssl asn1parse -genstr "UTF8String:?" -out content
> 
> I get a 6-byte file. If I understand correctly, it starts with a 2-byte header indicating the content length and then contains an encoded letter '?' I want. But the encoding of it is not UTF8, as the utf8 encoding of a cyrillic letter is 2 bytes long. 

When I do that I get the 6-byte file "0c 04 c3 91 c2 84", which looks like '?' is getting UTF-8 encoded twice (more exactly, asn1parse is receiving a utf8-encoded value but interpreting it as Latin-1, and then encoding that as UTF8, which produces nonsense).

The format of the "genstr" option is described in the ASN1_generate_nconf man page, which says you can prepend the format modifier "UTF8" to the specifier in order to tell genstr to interpret the value correctly. So this produces the output you want:

   FORMAT:UTF8,UTF8String:?

(Oddly, you can't use HEX with UTF8String. It seems like it would be convenient to be able to do so.)



From beldmit at gmail.com  Mon Apr 22 21:21:21 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 23 Apr 2019 00:21:21 +0300
Subject: asn1parse genstr question
In-Reply-To: <20190422182302.GB87116@straasha.imrryr.org>
References: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
 <20190422182302.GB87116@straasha.imrryr.org>
Message-ID: <CADqLbzJ_OHwWmEPUN+mRHOm2c5FnAHuAe0-=9GfRCEeNV7ZDGw@mail.gmail.com>

Dear Victor,

On Mon, Apr 22, 2019 at 9:23 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Sun, Apr 21, 2019 at 06:58:53PM +0300, Dmitry Belyavsky wrote:
>
> > When I use a command
> >
> > openssl asn1parse -genstr "UTF8String:?" -out content
> >
> > I get a 6-byte file. If I understand correctly, it starts with a 2-byte
> > header indicating the content length and then contains an encoded letter
> > '?' I want. But the encoding of it is not UTF8, as the utf8 encoding of a
> > cyrillic letter is 2 bytes long.
> >
> > Am I wrong? If the behavior I see is desired one, how can I convert the
> > result of the encoding to UTF8 using openssl internal API?
>
> By default the input string is assumed to contain single-byte octets,
> which are individually encoded as UTF-8.  This is rarely what you
> want if your input is not ASCII.  For actual UTF-8 input, you can
> use:
>
>     $ openssl asn1parse -out content -genstr 'FORMAT:UTF8,UTF8String:??
> ????! ?? ?? ?????, ??? ????!' # [1]
>         0:d=0  hl=2 l=  53 prim: UTF8STRING        :?? ????! ?? ?? ?????,
> ??? ????!
>
> The "genstr" format is described in, for example:
>
>     https://www.openssl.org/docs/man1.0.2/man3/ASN1_generate_nconf.html


Thank you very much for your answer and especially for a brilliant example
:)

I'm trying to implement RFC 8398 and I try to create a valid certificate
with EAI email in otherName.

I expected that a line in the config file

subjectAltName=otherName:1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8:??@
??.example.com <http://xn--pss25c.example.com>

will do the trick.
But I get an error
140642093051968:error:0D0B20C2:asn1 encoding
routines:ASN1_generate_v3:unknown tag:../crypto/asn1/asn1_gen.c:94:
140642093051968:error:220A4093:X509 V3 routines:a2i_GENERAL_NAME:othername
error:../crypto/x509v3/v3_alt.c:456:
140642093051968:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension:../crypto/x509v3/v3_conf.c:47:name=subjectAltName,
value=otherName:1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8:??@??.example.com
<http://xn--pss25c.example.com>

If I specify the otherName like
subjectAltName=otherName:1.3.6.1.5.5.7.8.9;UTF8:??@??.example.com
<http://xn--pss25c.example.com>

I do not get an error, but the encoding seems to be not UTF8, but ASCII.
Can this behavior be fixed?


>
> --
>         Viktor.
>
> [1]. http://www.mnemosyne.ru/homo/galich-6.html
>


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

From beldmit at gmail.com  Mon Apr 22 23:02:55 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 23 Apr 2019 02:02:55 +0300
Subject: asn1parse genstr question
In-Reply-To: <CADqLbzJ_OHwWmEPUN+mRHOm2c5FnAHuAe0-=9GfRCEeNV7ZDGw@mail.gmail.com>
References: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
 <20190422182302.GB87116@straasha.imrryr.org>
 <CADqLbzJ_OHwWmEPUN+mRHOm2c5FnAHuAe0-=9GfRCEeNV7ZDGw@mail.gmail.com>
Message-ID: <CADqLbzLTcwgE-s4qiCf8-BeWXET+8j-r2W4STP+BK1ybcqhh5w@mail.gmail.com>

Hello,

On Tue, Apr 23, 2019 at 12:21 AM Dmitry Belyavsky <beldmit at gmail.com> wrote:

> Dear Victor,
>
> On Mon, Apr 22, 2019 at 9:23 PM Viktor Dukhovni <
> openssl-users at dukhovni.org> wrote:
>
>> On Sun, Apr 21, 2019 at 06:58:53PM +0300, Dmitry Belyavsky wrote:
>>
>> > When I use a command
>> >
>> > openssl asn1parse -genstr "UTF8String:?" -out content
>> >
>> > I get a 6-byte file. If I understand correctly, it starts with a 2-byte
>> > header indicating the content length and then contains an encoded letter
>> > '?' I want. But the encoding of it is not UTF8, as the utf8 encoding of
>> a
>> > cyrillic letter is 2 bytes long.
>> >
>> > Am I wrong? If the behavior I see is desired one, how can I convert the
>> > result of the encoding to UTF8 using openssl internal API?
>>
>> By default the input string is assumed to contain single-byte octets,
>> which are individually encoded as UTF-8.  This is rarely what you
>> want if your input is not ASCII.  For actual UTF-8 input, you can
>> use:
>>
>>     $ openssl asn1parse -out content -genstr 'FORMAT:UTF8,UTF8String:??
>> ????! ?? ?? ?????, ??? ????!' # [1]
>>         0:d=0  hl=2 l=  53 prim: UTF8STRING        :?? ????! ?? ?? ?????,
>> ??? ????!
>>
>> The "genstr" format is described in, for example:
>>
>>     https://www.openssl.org/docs/man1.0.2/man3/ASN1_generate_nconf.html
>
>
> Thank you very much for your answer and especially for a brilliant example
> :)
>
> I'm trying to implement RFC 8398 and I try to create a valid certificate
> with EAI email in otherName.
>
> I expected that a line in the config file
>
> subjectAltName=otherName:1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8:??@
> ??.example.com <http://xn--pss25c.example.com>
>
> will do the trick.
> But I get an error
> 140642093051968:error:0D0B20C2:asn1 encoding
> routines:ASN1_generate_v3:unknown tag:../crypto/asn1/asn1_gen.c:94:
> 140642093051968:error:220A4093:X509 V3 routines:a2i_GENERAL_NAME:othername
> error:../crypto/x509v3/v3_alt.c:456:
> 140642093051968:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
> extension:../crypto/x509v3/v3_conf.c:47:name=subjectAltName,
> value=otherName:1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8:??@??.example.com
> <http://xn--pss25c.example.com>
>
> If I specify the otherName like
> subjectAltName=otherName:1.3.6.1.5.5.7.8.9;UTF8:??@??.example.com
> <http://xn--pss25c.example.com>
>
> I do not get an error, but the encoding seems to be not UTF8, but ASCII.
> Can this behavior be fixed?
>

I've got the clue.

The config string is passed to the X509V3_parse_list() function, which
treats comma as a separator, so the rest of the line is cut, and it causes
an error.
I've done a quick-and-dirty patch for my purposes that enforces FORMAT:UTF8
for SMTPUTF8 and succeeded.



>
>
>>
>> --
>>         Viktor.
>>
>> [1]. http://www.mnemosyne.ru/homo/galich-6.html
>>
>
>
> --
> SY, Dmitry Belyavsky
>


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

From openssl-users at dukhovni.org  Mon Apr 22 23:13:40 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 22 Apr 2019 19:13:40 -0400
Subject: asn1parse genstr question
In-Reply-To: <CADqLbzJ_OHwWmEPUN+mRHOm2c5FnAHuAe0-=9GfRCEeNV7ZDGw@mail.gmail.com>
References: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
 <20190422182302.GB87116@straasha.imrryr.org>
 <CADqLbzJ_OHwWmEPUN+mRHOm2c5FnAHuAe0-=9GfRCEeNV7ZDGw@mail.gmail.com>
Message-ID: <20190422231340.GC87116@straasha.imrryr.org>

On Tue, Apr 23, 2019 at 12:21:21AM +0300, Dmitry Belyavsky wrote:

> > For actual UTF-8 input, you can use:
> >
> >     $ openssl asn1parse -out content -genstr 'FORMAT:UTF8,UTF8String:?? ????! ?? ?? ?????, ??? ????!' # [1]
> >         0:d=0  hl=2 l=  53 prim: UTF8STRING        :?? ????! ?? ?? ?????, ??? ????!
> >
> > The "genstr" format is described in, for example:
> >
> >     https://www.openssl.org/docs/man1.0.2/man3/ASN1_generate_nconf.html
> 
> Thank you very much for your answer and especially for a brilliant example :)
> 
> I'm trying to implement RFC 8398 and I try to create a valid certificate
> with EAI email in otherName.
> 
> I expected that a line in the config file
> 
> subjectAltName=otherName:1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8:??@

The below worked for me:

	subjectName = @alts
	[alts]
	otherName = 1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8String:??????@????????.??

    $ openssl asn1parse -in eecert.pem
	0:d=0  hl=4 l= 858 cons: SEQUENCE          
	4:d=1  hl=4 l= 578 cons: SEQUENCE          
	8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
       10:d=3  hl=2 l=   1 prim: INTEGER           :02
       13:d=2  hl=2 l=   1 prim: INTEGER           :02
       16:d=2  hl=2 l=  13 cons: SEQUENCE          
       18:d=3  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
       29:d=3  hl=2 l=   0 prim: NULL              
       31:d=2  hl=2 l=  20 cons: SEQUENCE          
       33:d=3  hl=2 l=  18 cons: SET               
       35:d=4  hl=2 l=  16 cons: SEQUENCE          
       37:d=5  hl=2 l=   3 prim: OBJECT            :commonName
       42:d=5  hl=2 l=   9 prim: UTF8STRING        :Issuer CA
       53:d=2  hl=2 l=  32 cons: SEQUENCE          
       55:d=3  hl=2 l=  13 prim: UTCTIME           :190422230331Z
       70:d=3  hl=2 l=  15 prim: GENERALIZEDTIME   :21190423230331Z
       87:d=2  hl=2 l=  40 cons: SEQUENCE          
       89:d=3  hl=2 l=  38 cons: SET               
       91:d=4  hl=2 l=  36 cons: SEQUENCE          
       93:d=5  hl=2 l=   3 prim: OBJECT            :commonName
       98:d=5  hl=2 l=  29 prim: UTF8STRING        :?????? ????????
      129:d=2  hl=4 l= 290 cons: SEQUENCE          
      133:d=3  hl=2 l=  13 cons: SEQUENCE          
      135:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
      146:d=4  hl=2 l=   0 prim: NULL              
      148:d=3  hl=4 l= 271 prim: BIT STRING        
      423:d=2  hl=3 l= 160 cons: cont [ 3 ]        
      426:d=3  hl=3 l= 157 cons: SEQUENCE          
      429:d=4  hl=2 l=  29 cons: SEQUENCE          
      431:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Identifier
      436:d=5  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:041487FF5D9C758FDB282922102D0696834BD296A39D
      460:d=4  hl=2 l=  31 cons: SEQUENCE          
      462:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Identifier
      467:d=5  hl=2 l=  24 prim: OCTET STRING      [HEX DUMP]:30168014505CD4D6F75052F79EC51DA943AC099AD0079341
      493:d=4  hl=2 l=   9 cons: SEQUENCE          
      495:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
      500:d=5  hl=2 l=   2 prim: OCTET STRING      [HEX DUMP]:3000
      504:d=4  hl=2 l=  19 cons: SEQUENCE          
      506:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Extended Key Usage
      511:d=5  hl=2 l=  12 prim: OCTET STRING      [HEX DUMP]:300A06082B06010505070301
      525:d=4  hl=2 l=  59 cons: SEQUENCE          
      527:d=5  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative Name
      532:d=5  hl=2 l=  52 prim: OCTET STRING      [HEX DUMP]:3032A03006082B06010505070809A0240C22D0B2D0B8D0BAD182D0BED18040D0BDD0B0D0BFD180D0B8D0BCD0B5D1802ED180D184
      586:d=1  hl=2 l=  13 cons: SEQUENCE          
      588:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
      599:d=2  hl=2 l=   0 prim: NULL              
      601:d=1  hl=4 l= 257 prim: BIT STRING        

    $ openssl asn1parse -in eecert.pem -strparse 532
	0:d=0  hl=2 l=  50 cons: SEQUENCE
	2:d=1  hl=2 l=  48 cons: cont [ 0 ]
	4:d=2  hl=2 l=   8 prim: OBJECT            :1.3.6.1.5.5.7.8.9
       14:d=2  hl=2 l=  36 cons: cont [ 0 ]
       16:d=3  hl=2 l=  34 prim: UTF8STRING        :??????@????????.??

-- 
	Viktor.

From Chethan.Kumar at toshiba-tsip.com  Tue Apr 23 13:40:02 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Tue, 23 Apr 2019 13:40:02 +0000
Subject: DIfference between s2_srvr.c, s3_srvr.c, s23_srvr.c and t1_clnt.c
Message-ID: <447C096A3E2889439233CDD6DAB29F95B404977E@tosblrmbx04.TOSHIBA-TSIP.COM>

Dear all,

Can someone please explain the need for different files like s2_srvr.c, s3_srvr.c and s23_srvr.c in ssl folder.
I need to know the difference because ssl23_client_hello() is getting called for all communication happening using sslv3, tls1.0/1.1/1.2
Then what is the use of ssl3_client_hello() in s3_srvr.c and client_hello() in s2_srvr.c
Does ssl23_client_hello() is getting called internally for all versions?
If so, can some please point where does this internal call happens.

Thanks in advance,
Chethan Kumar

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190423/4b43730d/attachment.html>

From matt at openssl.org  Tue Apr 23 14:00:11 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Apr 2019 15:00:11 +0100
Subject: DIfference between s2_srvr.c, s3_srvr.c, s23_srvr.c and t1_clnt.c
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95B404977E@tosblrmbx04.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95B404977E@tosblrmbx04.TOSHIBA-TSIP.COM>
Message-ID: <2a522d21-4b04-0af3-83fe-0a2bbe8e6fb4@openssl.org>



On 23/04/2019 14:40, Chethan Kumar wrote:
> Dear all,
> 
> ?
> 
> Can someone please explain the need for different files like s2_srvr.c,
> s3_srvr.c and s23_srvr.c in ssl folder.
> 
> I need to know the difference because ssl23_client_hello() is getting called for
> all communication happening using sslv3, tls1.0/1.1/1.2
> 
> Then what is the use of ssl3_client_hello() in s3_srvr.c and client_hello() in
> s2_srvr.c
> 
> Does ssl23_client_hello() is getting called internally for all versions?
> 
> If so, can some please point where does this internal call happens.

s2_srvr.c processes SSLv2 only.
s3_srvr.c processes SSLv3 and above for a fixed protocol version (it does not do
version negotiation).

s23_srvr.c does version negotiation. It pulls apart the ClientHello that has
been received and works out what protocol version should be used. It then sets
the protocol version in the SSL object, pushes the ClientHello back into a read
buffer and restarts the process. If SSLv2 was selected then the client hello
processing in s2_srvr.c is used. If SSLv3 or above was selected then the client
hello processing in s3_srvr.c is used.

You can see the code to set the protocol version in the SSL object, and then
push the ClientHello back into the read buffer here:

https://github.com/openssl/openssl/blob/f937540ec40a5e838460b8f19d2eb722529126b8/ssl/s23_srvr.c#L598-L639

At the end of this function we call SSL_accept again to restart the process:

https://github.com/openssl/openssl/blob/f937540ec40a5e838460b8f19d2eb722529126b8/ssl/s23_srvr.c#L650

If you use SSLv2_server_method(), SSLv3_server_method(), TLSv1_server_method(),
TLSv1_1_server_method() or TLSv1_2_server_method() when you create your
SSL_CTX() then this "fixes" the protocol version at the specified level. In this
case s23_srvr.c is never used and you just go straight to s3_srvr.c (or s2_srvr.c).

If you use SSLv23_server_method() then version negotiation is used an you go to
s23_srvr.c initially.

In OpenSSL 1.1.0+ version negotiation was completely rewritten so this works
very differently there. The fixed protocol server methods are deprecated and you
are encouraged to use TLS_server_method() instead (which is the new name for
SSLv23_server_method).

Hope that helps

Matt


From Chethan.Kumar at toshiba-tsip.com  Wed Apr 24 07:05:33 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Wed, 24 Apr 2019 07:05:33 +0000
Subject: DIfference between s2_srvr.c, s3_srvr.c, s23_srvr.c and t1_clnt.c
In-Reply-To: <2a522d21-4b04-0af3-83fe-0a2bbe8e6fb4@openssl.org>
References: <447C096A3E2889439233CDD6DAB29F95B404977E@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2a522d21-4b04-0af3-83fe-0a2bbe8e6fb4@openssl.org>
Message-ID: <447C096A3E2889439233CDD6DAB29F95B40498F0@tosblrmbx04.TOSHIBA-TSIP.COM>

Thanks for the information.

I understood the flow.
Does t1_srvr.c is used to call respective TLS*_server_method in s3_srvr.c when tls1_get_server_method() is set while creating SSL_CTX()?
Is similar logic followed for openssl as client also? Like s2_clnt.c is called when SSLv2 is used.
S23_clnt.c is called for SSLv3 and above. Or is it different.?

Also, please let me know if there is any document/link which describes the codeflow when clienthello  is received.

Thanks in advance,
Chethan Kumar



-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
Sent: Tuesday, April 23, 2019 7:30 PM
To: openssl-users at openssl.org
Subject: Re: DIfference between s2_srvr.c, s3_srvr.c, s23_srvr.c and t1_clnt.c



On 23/04/2019 14:40, Chethan Kumar wrote:
> Dear all,
> 
> ?
> 
> Can someone please explain the need for different files like 
> s2_srvr.c, s3_srvr.c and s23_srvr.c in ssl folder.
> 
> I need to know the difference because ssl23_client_hello() is getting 
> called for all communication happening using sslv3, tls1.0/1.1/1.2
> 
> Then what is the use of ssl3_client_hello() in s3_srvr.c and 
> client_hello() in s2_srvr.c
> 
> Does ssl23_client_hello() is getting called internally for all versions?
> 
> If so, can some please point where does this internal call happens.

s2_srvr.c processes SSLv2 only.
s3_srvr.c processes SSLv3 and above for a fixed protocol version (it does not do version negotiation).

s23_srvr.c does version negotiation. It pulls apart the ClientHello that has been received and works out what protocol version should be used. It then sets the protocol version in the SSL object, pushes the ClientHello back into a read buffer and restarts the process. If SSLv2 was selected then the client hello processing in s2_srvr.c is used. If SSLv3 or above was selected then the client hello processing in s3_srvr.c is used.

You can see the code to set the protocol version in the SSL object, and then push the ClientHello back into the read buffer here:

https://github.com/openssl/openssl/blob/f937540ec40a5e838460b8f19d2eb722529126b8/ssl/s23_srvr.c#L598-L639

At the end of this function we call SSL_accept again to restart the process:

https://github.com/openssl/openssl/blob/f937540ec40a5e838460b8f19d2eb722529126b8/ssl/s23_srvr.c#L650

If you use SSLv2_server_method(), SSLv3_server_method(), TLSv1_server_method(),
TLSv1_1_server_method() or TLSv1_2_server_method() when you create your
SSL_CTX() then this "fixes" the protocol version at the specified level. In this case s23_srvr.c is never used and you just go straight to s3_srvr.c (or s2_srvr.c).

If you use SSLv23_server_method() then version negotiation is used an you go to s23_srvr.c initially.

In OpenSSL 1.1.0+ version negotiation was completely rewritten so this works very differently there. The fixed protocol server methods are deprecated and you are encouraged to use TLS_server_method() instead (which is the new name for SSLv23_server_method).

Hope that helps

Matt

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.


From matt at openssl.org  Wed Apr 24 11:22:36 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Apr 2019 12:22:36 +0100
Subject: DIfference between s2_srvr.c, s3_srvr.c, s23_srvr.c and t1_clnt.c
In-Reply-To: <447C096A3E2889439233CDD6DAB29F95B40498F0@tosblrmbx04.TOSHIBA-TSIP.COM>
References: <447C096A3E2889439233CDD6DAB29F95B404977E@tosblrmbx04.TOSHIBA-TSIP.COM>
 <2a522d21-4b04-0af3-83fe-0a2bbe8e6fb4@openssl.org>
 <447C096A3E2889439233CDD6DAB29F95B40498F0@tosblrmbx04.TOSHIBA-TSIP.COM>
Message-ID: <5e3099f0-7768-83e7-dc00-f5f88a413939@openssl.org>



On 24/04/2019 08:05, Chethan Kumar wrote:
> Thanks for the information.
> 
> I understood the flow. Does t1_srvr.c is used to call respective
> TLS*_server_method in s3_srvr.c when tls1_get_server_method() is set while
> creating SSL_CTX()?

Each protocol version has a corresponding SSL_METHOD structure which contains a
set of function pointers for protocol version specific implementations of
various functions, as well as other meta data about the protocol version. The
t1_srvr.c file just defines those SSL_METHOD structures for TLSv1, TLSv1.1 and
TLSv1.2. When you call SSL_CTX() you must supply a specific SSL_METHOD that
you're going to use which can either be one of the protocol version specific
methods such as those defined in t1_srvr.c (not recommended) or the generic
version flexible SSLv23_server_method().


> Is similar logic followed for openssl as client also?
> Like s2_clnt.c is called when SSLv2 is used. S23_clnt.c is called for SSLv3
> and above. Or is it different.?

Yes, this is very similar.

Matt

From s.sathishreddy308 at gmail.com  Wed Apr 24 11:48:14 2019
From: s.sathishreddy308 at gmail.com (sathish reddy s)
Date: Wed, 24 Apr 2019 17:18:14 +0530
Subject: Shall I expect SHA3 support in OpenSSL-1.0.2 series?
Message-ID: <CAA0TSE3YRLBBgmntUVn04a5w4VN8xqXK8h79S511Koj1WO9N9A@mail.gmail.com>

*Hi All,*

*I saw Sha3 support in OpenSSL-1.1.1 branch. Shall I expect sha3
support in OpenSSL-1.0.2 branch?*


*Regards,*

*Sathish.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190424/90ab9a88/attachment-0001.html>

From matt at openssl.org  Wed Apr 24 11:58:50 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Apr 2019 12:58:50 +0100
Subject: Shall I expect SHA3 support in OpenSSL-1.0.2 series?
In-Reply-To: <CAA0TSE3YRLBBgmntUVn04a5w4VN8xqXK8h79S511Koj1WO9N9A@mail.gmail.com>
References: <CAA0TSE3YRLBBgmntUVn04a5w4VN8xqXK8h79S511Koj1WO9N9A@mail.gmail.com>
Message-ID: <08699b50-f3ce-1bd5-2a3f-1ff035659dfa@openssl.org>



On 24/04/2019 12:48, sathish reddy s wrote:
> /Hi All,/
> 
> /I saw Sha3 support in OpenSSL-1.1.1 branch. Shall I expect sha3 support in
> OpenSSL-1.0.2 branch?/

No. As a rule we don't add new features to stable branches.

Matt


From s.sathishreddy308 at gmail.com  Wed Apr 24 12:08:29 2019
From: s.sathishreddy308 at gmail.com (sathish reddy s)
Date: Wed, 24 Apr 2019 17:38:29 +0530
Subject: Shall I expect SHA3 support in OpenSSL-1.0.2 series?
In-Reply-To: <08699b50-f3ce-1bd5-2a3f-1ff035659dfa@openssl.org>
References: <CAA0TSE3YRLBBgmntUVn04a5w4VN8xqXK8h79S511Koj1WO9N9A@mail.gmail.com>
 <08699b50-f3ce-1bd5-2a3f-1ff035659dfa@openssl.org>
Message-ID: <CAA0TSE2TkUkwietVWUijRHgjPkoM-3fbnD0mOQ+RgwVEwaag+g@mail.gmail.com>

Hi,

I found the following line at https://www.openssl.org/source/
"Our previous LTS version (1.0.2 series) will continue to be supported
until 31st December 2019 (security fixes only during the last year of
support)".

Is there any chance to add SHA3 support in the upcoming releases?



On Wed, Apr 24, 2019 at 5:29 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 24/04/2019 12:48, sathish reddy s wrote:
> > /Hi All,/
> >
> > /I saw Sha3 support in OpenSSL-1.1.1 branch. Shall I expect sha3 support
> in
> > OpenSSL-1.0.2 branch?/
>
> No. As a rule we don't add new features to stable branches.
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190424/8acccfde/attachment.html>

From matt at openssl.org  Wed Apr 24 12:32:40 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Apr 2019 13:32:40 +0100
Subject: Shall I expect SHA3 support in OpenSSL-1.0.2 series?
In-Reply-To: <CAA0TSE2TkUkwietVWUijRHgjPkoM-3fbnD0mOQ+RgwVEwaag+g@mail.gmail.com>
References: <CAA0TSE3YRLBBgmntUVn04a5w4VN8xqXK8h79S511Koj1WO9N9A@mail.gmail.com>
 <08699b50-f3ce-1bd5-2a3f-1ff035659dfa@openssl.org>
 <CAA0TSE2TkUkwietVWUijRHgjPkoM-3fbnD0mOQ+RgwVEwaag+g@mail.gmail.com>
Message-ID: <191863a5-0a43-ef8d-ace5-3477d11e1e1a@openssl.org>



On 24/04/2019 13:08, sathish reddy s wrote:
> Hi,
> 
> I found the following line at?https://www.openssl.org/source/
> "Our previous LTS version (1.0.2 series) will continue to be supported until
> 31st December 2019 (security fixes only during the last year of support)".
> 
> Is there any chance to add SHA3 support in the upcoming releases?

No. 1.0.2 is a stable branch. Any releases of stable branches are for bug and
security fixes. In the case of 1.0.2 it is in the last year of support so its
only getting security fixes. SHA3 is a feature and does not qualify.

Matt

> 
> 
> 
> On Wed, Apr 24, 2019 at 5:29 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 24/04/2019 12:48, sathish reddy s wrote:
>     > /Hi All,/
>     >
>     > /I saw Sha3 support in OpenSSL-1.1.1 branch. Shall I expect sha3 support in
>     > OpenSSL-1.0.2 branch?/
> 
>     No. As a rule we don't add new features to stable branches.
> 
>     Matt
> 

From Michael.Wojcik at microfocus.com  Wed Apr 24 13:32:23 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 24 Apr 2019 13:32:23 +0000
Subject: Shall I expect SHA3 support in OpenSSL-1.0.2 series?
In-Reply-To: <191863a5-0a43-ef8d-ace5-3477d11e1e1a@openssl.org>
References: <CAA0TSE3YRLBBgmntUVn04a5w4VN8xqXK8h79S511Koj1WO9N9A@mail.gmail.com>
 <08699b50-f3ce-1bd5-2a3f-1ff035659dfa@openssl.org>
 <CAA0TSE2TkUkwietVWUijRHgjPkoM-3fbnD0mOQ+RgwVEwaag+g@mail.gmail.com>
 <191863a5-0a43-ef8d-ace5-3477d11e1e1a@openssl.org>
Message-ID: <BYAPR18MB29189F965DDA3E2C1EAEDFC3F93C0@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Matt Caswell
> Sent: Wednesday, April 24, 2019 08:33
>
>
> On 24/04/2019 13:08, sathish reddy s wrote:
> >
> > I found the following line at https://www.openssl.org/source/
> > "Our previous LTS version (1.0.2 series) will continue to be supported until
> > 31st December 2019 (security fixes only during the last year of support)".
> >
> > Is there any chance to add SHA3 support in the upcoming releases?
>
> No. 1.0.2 is a stable branch. Any releases of stable branches are for bug and
> security fixes. In the case of 1.0.2 it is in the last year of support so its
> only getting security fixes. SHA3 is a feature and does not qualify.

Note that, as Matt wrote, OpenSSL 1.0.2 is in its final year of support. Security issues will be fixed for the next eight months. That's it.

Everyone should be moving to 1.1 now, unless they need FIPS 140-2 validation. Frankly, even if you need FIPS, you should be working on a 1.1-based branch, in anticipation of moving to FIPS-validated OpenSSL 3 (or 4, if that numbering change is accepted) when it's available. The alternative is to support 1.0.2 yourself, and I'd estimate that 99% of OpenSSL users aren't qualified to do that.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From beldmit at gmail.com  Wed Apr 24 19:09:52 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Wed, 24 Apr 2019 22:09:52 +0300
Subject: asn1parse genstr question
In-Reply-To: <20190422231340.GC87116@straasha.imrryr.org>
References: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
 <20190422182302.GB87116@straasha.imrryr.org>
 <CADqLbzJ_OHwWmEPUN+mRHOm2c5FnAHuAe0-=9GfRCEeNV7ZDGw@mail.gmail.com>
 <20190422231340.GC87116@straasha.imrryr.org>
Message-ID: <CADqLbzKQT3XWp0EKnM9LbLkxNv5f_DWBsqFjQwf8dz+mNZ67cg@mail.gmail.com>

Dear Victor,

The below worked for me:
>
>         subjectName = @alts
>         [alts]
>         otherName =
> 1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8String:??????@????????.??
>

Thank you! It works, though it should be subjectAltName instead of
subjectName

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

From phill at thesusis.net  Wed Apr 24 19:58:30 2019
From: phill at thesusis.net (Phillip Susi)
Date: Wed, 24 Apr 2019 15:58:30 -0400
Subject: Self signed cert authorization
Message-ID: <87bm0vyy3d.fsf@vps.thesusis.net>

I've been trying to convince git send-email to connect to my personal
smtp server without success.  It keeps complaining that the cert is
self-signed.  I thought all I had to do was add the cert to
/etc/ssl/certs and that should fix it, but it doesn't.  Even without
doing this, and using -verify_return_error, openssl s_client does not
refuse to connect to the server.  Why is this and what else do I have to
do to convince the system that this self signed cert is OK?


From jb-openssl at wisemo.com  Wed Apr 24 20:34:01 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 24 Apr 2019 22:34:01 +0200
Subject: Self signed cert authorization
In-Reply-To: <87bm0vyy3d.fsf@vps.thesusis.net>
References: <87bm0vyy3d.fsf@vps.thesusis.net>
Message-ID: <6563ba83-dfd5-cf31-01f4-bfaa08df0ac3@wisemo.com>

On 24/04/2019 21:58, Phillip Susi wrote:
> I've been trying to convince git send-email to connect to my personal
> smtp server without success.  It keeps complaining that the cert is
> self-signed.  I thought all I had to do was add the cert to
> /etc/ssl/certs and that should fix it, but it doesn't.  Even without
> doing this, and using -verify_return_error, openssl s_client does not
> refuse to connect to the server.  Why is this and what else do I have to
> do to convince the system that this self signed cert is OK?
>
Three suggestions, depending on what git send-email and your system
does:

1. If you are on a somewhat recent Debian (or similar) system, move
 ? your cert from /etc/ssl/certs/ to /usr/local/share/ca-certificates/
 ? and rerun
 ? # dpkg-reconfigure ca-certificates
 ? # dpkg-reconfigure ca-certificates
 ? (Yes, run it twice, it has a bug if run only once).
 ? (This does the next two suggestions in the way the system expects,
 ? even though the list of certificates shown by the configuration
 ? dialogs doesn't include your own certificates).

2. cd to /etc/ssl/certs and run the command
 ? /etc/sssl/certs# c_rehash
 ? (This updates the numeric symlinks to certificates so openssl can
 ? more easily find them).

3. If your system generates/maintains a big file with all the
 ? trusted certs concatenated, concatenate your extra cert to the
 ? end of that file.


Enjoy

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


From openssl-users at dukhovni.org  Wed Apr 24 22:23:58 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 24 Apr 2019 18:23:58 -0400
Subject: asn1parse genstr question
In-Reply-To: <CADqLbzKQT3XWp0EKnM9LbLkxNv5f_DWBsqFjQwf8dz+mNZ67cg@mail.gmail.com>
References: <CADqLbzJL1RHT3Y9=wymeBddef7URHo2SMwLv0RCW1JOacdWiCQ@mail.gmail.com>
 <20190422182302.GB87116@straasha.imrryr.org>
 <CADqLbzJ_OHwWmEPUN+mRHOm2c5FnAHuAe0-=9GfRCEeNV7ZDGw@mail.gmail.com>
 <20190422231340.GC87116@straasha.imrryr.org>
 <CADqLbzKQT3XWp0EKnM9LbLkxNv5f_DWBsqFjQwf8dz+mNZ67cg@mail.gmail.com>
Message-ID: <20190424222357.GF87116@straasha.imrryr.org>

On Wed, Apr 24, 2019 at 10:09:52PM +0300, Dmitry Belyavsky wrote:

> The below worked for me:
> >
> >         subjectName = @alts
> >         [alts]
> >         otherName = 1.3.6.1.5.5.7.8.9;FORMAT:UTF8,UTF8String:??????@????????.??
> 
> Thank you!

You're very welcome.

> It works, though it should be subjectAltName instead of subjectName

Yes, of course, sorry about that... Should have pasted that too
from my script rather than retyping.

-- 
	Viktor.

From mattlindn at gmail.com  Wed Apr 24 23:11:30 2019
From: mattlindn at gmail.com (Matthew Lindner)
Date: Wed, 24 Apr 2019 16:11:30 -0700
Subject: Caching CRL/Cert verification
Message-ID: <CAEGbdicDWawEovr9zQxQkDw8eJthFZqUx6cZX7uLGPLZKe9riA@mail.gmail.com>

How do you cache the results of a CRL or Cert verification? When
inspecting the code I see that check_cert() gets called for every
certificate and the code re-verifies every used CRL on every
certificate check. This is similarly done for Certificates where it is
re-verified even if it is already verified. How does one cache that
the signature of a certificate/CRL is valid so that the verification
process is not repeated?

-- Matthew

From swamy.j-s at in.abb.com  Thu Apr 25 08:06:53 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Thu, 25 Apr 2019 08:06:53 +0000
Subject: Where to copy custom openssl engine library in openssl 1.1.0
Message-ID: <HE1PR0602MB3643CE7AE9FACA4835653DB8963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>

Am working in Ubuntu 18.04 with openssl 1.1.0g version. I built a custom openssl engine and now i want to use this engine instead of default openssl engine.

My engine library name is libstoreengine.so and i copied this to /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/ path.



When i run my application the it says Store Engine not found. There is path issue here, am i copying the library in right path? I copied my library in /lib/x86_64-linux-gnu still am getting same error.

Please let me know the right path where i have to copy this engine?

Thanks and Regards,
SWAMY J S

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

From beldmit at gmail.com  Thu Apr 25 08:13:54 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Thu, 25 Apr 2019 11:13:54 +0300
Subject: Where to copy custom openssl engine library in openssl 1.1.0
In-Reply-To: <HE1PR0602MB3643CE7AE9FACA4835653DB8963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB3643CE7AE9FACA4835653DB8963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <CADqLbz+m75EGh-CPGKa9rd1ZHtnBuHGsenPPbXhef-C6bTqG7A@mail.gmail.com>

Hello,

You should load your engine via config file.

It may look like
=====
openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
storeengine = store_section

[store_section]
engine_id = store
dynamic_path = /usr/local/lib/engines/storeengine.so
========

Your application should load the config file, the way it works is different
for different versions.


On Thu, Apr 25, 2019 at 11:07 AM Swamy J-S <swamy.j-s at in.abb.com> wrote:

> Am working in Ubuntu 18.04 with openssl 1.1.0g version. I built a custom
> openssl engine and now i want to use this engine instead of default openssl
> engine.
>
> My engine library name is libstoreengine.so and i copied this to
> /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/ path.
>
>
>
> When i run my application the it says Store Engine not found. There is
> path issue here, am i copying the library in right path? I copied my
> library in /lib/x86_64-linux-gnu still am getting same error.
>
> Please let me know the right path where i have to copy this engine?
>
>
>
> Thanks and Regards,
>
> *SWAMY J S*
>
>
>


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

From swamy.j-s at in.abb.com  Thu Apr 25 08:36:04 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Thu, 25 Apr 2019 08:36:04 +0000
Subject: Where to copy custom openssl engine library in openssl 1.1.0
In-Reply-To: <CADqLbz+m75EGh-CPGKa9rd1ZHtnBuHGsenPPbXhef-C6bTqG7A@mail.gmail.com>
References: <HE1PR0602MB3643CE7AE9FACA4835653DB8963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
 <CADqLbz+m75EGh-CPGKa9rd1ZHtnBuHGsenPPbXhef-C6bTqG7A@mail.gmail.com>
Message-ID: <HE1PR0602MB36430D6BCD54D81F756F0A2F963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>

Hi, Thanks for reply. I have a doubt here. Which config file you are referring too? Is there any file called ?config? which is already existing somewhere or should I create a dummy file called config?

Just now I created a dummy file ?config? and added the details you sent in this file.

Also added ?export OPENSSL_CONF=path_to_config? in /etc/environment file. And ran the command ?openssl engine store -t -c?.
Still am getting same error as store not found when I run my application.

Thanks and Regards,
SWAMY J S

From: Dmitry Belyavsky <beldmit at gmail.com>
Sent: Thursday, April 25, 2019 1:44 PM
To: Swamy J-S <swamy.j-s at in.abb.com>
Cc: openssl-users at openssl.org
Subject: Re: Where to copy custom openssl engine library in openssl 1.1.0

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello,

You should load your engine via config file.

It may look like
=====
openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
storeengine = store_section

[store_section]
engine_id = store
dynamic_path = /usr/local/lib/engines/storeengine.so
========

Your application should load the config file, the way it works is different for different versions.


On Thu, Apr 25, 2019 at 11:07 AM Swamy J-S <swamy.j-s at in.abb.com<mailto:swamy.j-s at in.abb.com>> wrote:

Am working in Ubuntu 18.04 with openssl 1.1.0g version. I built a custom openssl engine and now i want to use this engine instead of default openssl engine.

My engine library name is libstoreengine.so and i copied this to /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/ path.



When i run my application the it says Store Engine not found. There is path issue here, am i copying the library in right path? I copied my library in /lib/x86_64-linux-gnu still am getting same error.

Please let me know the right path where i have to copy this engine?

Thanks and Regards,
SWAMY J S



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

From beldmit at gmail.com  Thu Apr 25 08:55:08 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Thu, 25 Apr 2019 11:55:08 +0300
Subject: Where to copy custom openssl engine library in openssl 1.1.0
In-Reply-To: <HE1PR0602MB36430D6BCD54D81F756F0A2F963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB3643CE7AE9FACA4835653DB8963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
 <CADqLbz+m75EGh-CPGKa9rd1ZHtnBuHGsenPPbXhef-C6bTqG7A@mail.gmail.com>
 <HE1PR0602MB36430D6BCD54D81F756F0A2F963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <CADqLbzJBFS+7qXb4hUsSyEbE-Df_G4EOC+LH-PFoGqznodYA9Q@mail.gmail.com>

Hello,

On Thu, Apr 25, 2019 at 11:36 AM Swamy J-S <swamy.j-s at in.abb.com> wrote:

> Hi, Thanks for reply. I have a doubt here. Which config file you are
> referring too? Is there any file called ?*config*? which is already
> existing somewhere or should I create a dummy file called config?
>
>
>
> Just now I created a dummy file ?*config*? and added the details you sent
> in this file.
>
>
>
> Also added ?*export OPENSSL_CONF=path_to_config*? in /etc/environment
> file. And ran the command ?*openssl engine store -t -c*?.
>

Did you specify the correct dynamic_path?
Does the strace (in Linux) command report, that the config file and the
engine is read?

Still am getting same error as store not found when I run my application.
>
>
>
> Thanks and Regards,
>
> *SWAMY J S*
>
>
>
> *From:* Dmitry Belyavsky <beldmit at gmail.com>
> *Sent:* Thursday, April 25, 2019 1:44 PM
> *To:* Swamy J-S <swamy.j-s at in.abb.com>
> *Cc:* openssl-users at openssl.org
> *Subject:* Re: Where to copy custom openssl engine library in openssl
> 1.1.0
>
>
>
> *CAUTION:* This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hello,
>
>
>
> You should load your engine via config file.
>
>
>
> It may look like
>
> =====
>
> openssl_conf = openssl_def
>
>
>
> [openssl_def]
>
> engines = engine_section
>
>
>
> [engine_section]
>
> storeengine = store_section
>
>
>
> [store_section]
>
> engine_id = store
>
> dynamic_path = /usr/local/lib/engines/storeengine.so
>
> ========
>
>
>
> Your application should load the config file, the way it works is
> different for different versions.
>
>
>
>
>
> On Thu, Apr 25, 2019 at 11:07 AM Swamy J-S <swamy.j-s at in.abb.com> wrote:
>
> Am working in Ubuntu 18.04 with openssl 1.1.0g version. I built a custom
> openssl engine and now i want to use this engine instead of default openssl
> engine.
>
> My engine library name is libstoreengine.so and i copied this to
> /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/ path.
>
>
>
> When i run my application the it says Store Engine not found. There is
> path issue here, am i copying the library in right path? I copied my
> library in /lib/x86_64-linux-gnu still am getting same error.
>
> Please let me know the right path where i have to copy this engine?
>
>
>
> Thanks and Regards,
>
> *SWAMY J S*
>
>
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>


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

From hkario at redhat.com  Thu Apr 25 16:57:10 2019
From: hkario at redhat.com (Hubert Kario)
Date: Thu, 25 Apr 2019 18:57:10 +0200
Subject: Self signed cert authorization
In-Reply-To: <87bm0vyy3d.fsf@vps.thesusis.net>
References: <87bm0vyy3d.fsf@vps.thesusis.net>
Message-ID: <2279080.oY7kpxCk8f@pintsize.usersys.redhat.com>

On Wednesday, 24 April 2019 21:58:30 CEST Phillip Susi wrote:
> I've been trying to convince git send-email to connect to my personal
> smtp server without success.  It keeps complaining that the cert is
> self-signed.  I thought all I had to do was add the cert to
> /etc/ssl/certs and that should fix it, but it doesn't.  Even without
> doing this, and using -verify_return_error, openssl s_client does not
> refuse to connect to the server.  Why is this and what else do I have to
> do to convince the system that this self signed cert is OK?

what distribution, which version of openssl?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190425/fcc538a0/attachment.sig>

From phill at thesusis.net  Thu Apr 25 17:21:05 2019
From: phill at thesusis.net (Phillip Susi)
Date: Thu, 25 Apr 2019 13:21:05 -0400
Subject: Self signed cert authorization
In-Reply-To: <6563ba83-dfd5-cf31-01f4-bfaa08df0ac3@wisemo.com>
References: <87bm0vyy3d.fsf@vps.thesusis.net>
 <6563ba83-dfd5-cf31-01f4-bfaa08df0ac3@wisemo.com>
Message-ID: <87mukexapq.fsf@vps.thesusis.net>


Jakob Bohm via openssl-users writes:

> 2. cd to /etc/ssl/certs and run the command
>   /etc/sssl/certs# c_rehash
>   (This updates the numeric symlinks to certificates so openssl can
>   more easily find them).

Thanks, I ended up finding c_rehash and that did the trick.

From andevishnu at gmail.com  Fri Apr 26 05:05:01 2019
From: andevishnu at gmail.com (Ande Vishnuvardhan Reddy)
Date: Fri, 26 Apr 2019 10:35:01 +0530
Subject: Reg: Building Openssl 1.1.1b for Borland
Message-ID: <CA+mONGU74=7pnNdOmbJ-Crpp1y=swa5gTfQ_MbdB1s-UEGF-og@mail.gmail.com>

Hi,

We would like to build Openssl 1.1.1b with Borland compiler (bcc32 -
Embarcadero C++ 7.40). Seems support for Borland is removed from 1.1.x .

Could you please help in building Openssl 1.1.1b with Borland?
Please suggest what are the conf files to be added to generate makefile.

Thanks in advance.


Regards,
Vishnu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190426/2920cd47/attachment.html>

From levitte at openssl.org  Fri Apr 26 06:19:25 2019
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 26 Apr 2019 08:19:25 +0200
Subject: Reg: Building Openssl 1.1.1b for Borland
In-Reply-To: <CA+mONGU74=7pnNdOmbJ-Crpp1y=swa5gTfQ_MbdB1s-UEGF-og@mail.gmail.com>
References: <CA+mONGU74=7pnNdOmbJ-Crpp1y=swa5gTfQ_MbdB1s-UEGF-og@mail.gmail.com>
Message-ID: <87o94t9tle.wl-levitte@openssl.org>

On Fri, 26 Apr 2019 07:05:01 +0200,
Ande Vishnuvardhan Reddy wrote:
> We would like to build Openssl 1.1.1b with Borland compiler (bcc32 - Embarcadero C++ 7.40). Seems
> support for Borland is removed from 1.1.x .

It was dropped, that's true.  The main reason was lack of docs (or not
being able to find the docs)

> Could you please help in building Openssl 1.1.1b with Borland?
> Please suggest what are the conf files to be added to generate makefile.

It's not just about the conf file, you most probably need a separate
Makefile template too.  For starters, I assume Borland comes with some
kind of make utility...  or do Borland users use something else?
What's its default Makefile name?

Cheers,
Richard ( slowly working out something that is more flexible )

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

From jb-openssl at wisemo.com  Fri Apr 26 11:58:22 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 26 Apr 2019 13:58:22 +0200
Subject: Reg: Building Openssl 1.1.1b for Borland
In-Reply-To: <87o94t9tle.wl-levitte@openssl.org>
References: <CA+mONGU74=7pnNdOmbJ-Crpp1y=swa5gTfQ_MbdB1s-UEGF-og@mail.gmail.com>
 <87o94t9tle.wl-levitte@openssl.org>
Message-ID: <9aa795bc-00a1-9165-fbd1-822b33eddea0@wisemo.com>

On 26/04/2019 08:19, Richard Levitte wrote:
> On Fri, 26 Apr 2019 07:05:01 +0200,
> Ande Vishnuvardhan Reddy wrote:
>> We would like to build Openssl 1.1.1b with Borland compiler (bcc32 - Embarcadero C++ 7.40). Seems
>> support for Borland is removed from 1.1.x .
> It was dropped, that's true.  The main reason was lack of docs (or not
> being able to find the docs)
>
>> Could you please help in building Openssl 1.1.1b with Borland?
>> Please suggest what are the conf files to be added to generate makefile.
> It's not just about the conf file, you most probably need a separate
> Makefile template too.  For starters, I assume Borland comes with some
> kind of make utility...  or do Borland users use something else?
> What's its default Makefile name?
At least older versions (5.x) included a MAKE.EXE which was more
predictable than MS's NMAKE.EXE.? The compilers could be invoked
from any other make tool (nmake, GNU make etc.), but Borland's
MAKE.EXE had an option to extract source file and header
dependencies directly from the object files being checked for
staleness, thus allowing simpler rules that don't mention all the
used headers.? However I guess the OpenSSL build system already
contains the needed dependencies anyway.

Also, Borland C/C++ used to stick to the old OMF object file format,
not the COFF format used by Microsoft tools.

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 John.Unsworth at synchronoss.com  Mon Apr 29 14:54:23 2019
From: John.Unsworth at synchronoss.com (John Unsworth)
Date: Mon, 29 Apr 2019 14:54:23 +0000
Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
Message-ID: <DM6PR07MB4650148D8EE6592229C38A83F5390@DM6PR07MB4650.namprd07.prod.outlook.com>

We are using OpenSSL 1.1.0h on Linux to send operations to LDAP servers. We use SSL_read() to receive the replies on a non-blocking socket. The vast majority of times SSL_read() returns >0, SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE as per the spec. However we are very occasionally seeing SSL_ERROR_SYSCALL with errno 11 (EAGAIN) which would seem to be the result of a platform socket read(() or write() when blocking would occur. Is this expected behaviour? We have changed our code to treat this as SSL_ERROR_WANT_READ or SSL_WANT_WRITE depending on the result of SSL_want_write(). Are we correct?

Regards,
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190429/14ec978b/attachment.html>

From jgh at wizmail.org  Mon Apr 29 15:35:18 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 29 Apr 2019 16:35:18 +0100
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <20190410002525.GG87116@straasha.imrryr.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
 <E2CC41D6-0DBC-4F99-B66A-A4FC2EEF4505@dukhovni.org>
 <20190404151623.GT1347@straasha.imrryr.org>
 <16652dc5-6eef-f500-8cea-7ed029e5aba5@wizmail.org>
 <20190410002525.GG87116@straasha.imrryr.org>
Message-ID: <0332e6c2-118d-4e35-ee05-915e14a0d14b@wizmail.org>

On 10/04/2019 01:25, Viktor Dukhovni wrote:
> In Postfix, we implement the new session callbacks and then don't
> care when the tickets arrive.  Whenever they do arrive the callback
> happens, and the client session cache is updated at that point.
> 
>     https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L531-L556
> 

https://www.openssl.org/docs/manmaster/man3/SSL_CTX_sess_set_new_cb.html

documents SSL_CTX_sess_set_new_cb as being for "server side".  You seem
to be using it client-side:

	SSL_CTX_sess_set_new_cb(client_ctx, new_client_session_cb);

Is this valid?
-- 
Cheers,
  Jeremy

From openssl-users at dukhovni.org  Mon Apr 29 15:48:52 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 29 Apr 2019 11:48:52 -0400
Subject: SSL_SESSION_set1_ticket ?
In-Reply-To: <0332e6c2-118d-4e35-ee05-915e14a0d14b@wizmail.org>
References: <0b1b916f-fc33-b779-3cad-fb43b686cde1@wizmail.org>
 <EA36EAB2-79D8-4B06-B2BC-8D5B66547B88@dukhovni.org>
 <4adab08a-6372-a104-e573-a32780637d83@wizmail.org>
 <019EAD57-E51E-48BC-8B01-299E995BDF2A@dukhovni.org>
 <2d8646cc-b319-90c9-e8d7-50a07df88f41@wizmail.org>
 <EA37A055-576D-471E-AA84-239736ED7936@dukhovni.org>
 <dfb8a73c-6918-2c1c-7602-c92a9f2afa6d@wizmail.org>
 <E2CC41D6-0DBC-4F99-B66A-A4FC2EEF4505@dukhovni.org>
 <20190404151623.GT1347@straasha.imrryr.org>
 <16652dc5-6eef-f500-8cea-7ed029e5aba5@wizmail.org>
 <20190410002525.GG87116@straasha.imrryr.org>
 <0332e6c2-118d-4e35-ee05-915e14a0d14b@wizmail.org>
Message-ID: <4B1D27DD-6A62-48F2-A34C-40560F2BD13D@dukhovni.org>



> On Apr 29, 2019, at 11:35 AM, Jeremy Harris <jgh at wizmail.org> wrote:
> 
> documents SSL_CTX_sess_set_new_cb as being for "server side".  You seem
> to be using it client-side:
> 
> 	SSL_CTX_sess_set_new_cb(client_ctx, new_client_session_cb);
> 
> Is this valid?

Postfix sessions caches on both sides of the connection.  Yes, the
callback is valid on both sides.

-- 
	Viktor.


From jimm at bearriver.com  Mon Apr 29 18:50:07 2019
From: jimm at bearriver.com (Jim Morris)
Date: Mon, 29 Apr 2019 11:50:07 -0700
Subject: OpenSSL 1.1.1b exceptions in CRYPO_malloc for Windows Mobile 6.5
 (ARM), POCKET PC
Message-ID: <67139639-b29b-3855-9c15-946cb7d35a44@bearriver.com>

Hi all,

I attempting to build OpenSSL 1.1.1b static libraries for our app on 
Windows Mobile 6.5 (ARM) targeting the POCKET PC SDK using Visual Studio 
2005 for use with gSoap.? I know this stuff is ancient, but...

I can build and run OpenSSL 1.0.2 so it isn't a crisis until perhaps 
after end of year, but it would be nice to be up-to-date and support TLS 
1.3.

I've followed the instructions graciously posted by Souju TANAKA, 
https://qiita.com/souju/items/94117c024862f57459c3#fn3, but I'm getting 
exceptions in CRYPO_malloc when initializing. gSoap hence OpenSSL is 
normally running in a thread.? I' tried initializing in both main thread 
and sync thread via gSoap initialized OpenSSL.

 ??? #if OPENSSL_VERSION_NUMBER < 0x10100000L
 ??? ??? SSL_library_init();
 ??? #else
 ??? ??? uint64_t? opts = 0;
 ??? ??? OPENSSL_init_ssl( opts, NULL);
 ??? #endif

Exception details:
Note the exception is NOT on the first CRYPO_malloc call.
Data Abort: Thread=8d9d8688 Proc=807a3b10 '<app-name>.exe'
AKY=00008001 PC=03f6b630(coredll.dll+0x00022630) 
RA=21ac80c8(ppp.dll+0x000180c8) BVA=221b8130 FSR=00000005
First-chance exception at 0x03f6b630 in <app-name>.exe: 0xC0000005: 
Access violation reading location 0x001b8130.
Stack:
 ???? 0x03f6b630
 ???? 0x03f6b758
 ???? 0x03f6b968
 ???? 0x03f6ada0
 ???? 0x03f99388
 ???? 0x03f993b8
 >??? <app-name>.exe!CRYPTO_malloc(unsigned int num = 96, const char* 
file = 0x00c66c20, int line = 51) Line: 222, Byte Offsets: 0xa4??? C
 ???? <app-name>.exe!CRYPTO_zalloc(unsigned int num = 96, const char* 
file = 0x00c66c20, int line = 51) Line: 230, Byte Offsets: 0x20??? C
 ???? <app-name>.exe!OPENSSL_LH_new(unsigned long int (const void*)* h = 
0x00666d14, int (const void*, const void*)* c = 0x00666c18) Line: 51, 
Byte Offsets: 0x20??? C
 ???? <app-name>.exe!lh_OBJ_NAME_new(unsigned long int (obj_name_st*)* 
hfn = 0x00666d14, int (obj_name_st*, obj_name_st*)* cfn = 0x00666c18) 
Line: 12, Byte Offsets: 0x1c??? C
 ???? <app-name>.exe!o_names_init(void) Line: 70, Byte Offsets: 0x1c??? C
 ???? <app-name>.exe!o_names_init_ossl_(void) Line: 67, Byte Offsets: 
0x0c??? C
 ???? <app-name>.exe!CRYPTO_THREAD_run_once(long int* once = 0x00dae0f0, 
void (void)* init = 0x006667e4) Line: 93, Byte Offsets: 0x68??? C
 ???? <app-name>.exe!OBJ_NAME_init(void) Line: 78, Byte Offsets: 0x14??? C
 ???? <app-name>.exe!OBJ_NAME_add(const char* name = 0x00c58e80, int 
type = 2, const char* data = 0x00c7944c) Line: 213, Byte Offsets: 0x1c??? C
 ???? <app-name>.exe!EVP_add_cipher(evp_cipher_st* c = 0x00c7944c) Line: 
25, Byte Offsets: 0x48??? C
 ???? <app-name>.exe!openssl_add_all_ciphers_int(void) Line: 22, Byte 
Offsets: 0x18??? C
 ???? <app-name>.exe!ossl_init_add_all_ciphers(void) Line: 255, Byte 
Offsets: 0x0c??? C
 ???? <app-name>.exe!ossl_init_add_all_ciphers_ossl_(void) Line: 242, 
Byte Offsets: 0x0c??? C
 ???? <app-name>.exe!CRYPTO_THREAD_run_once(long int* once = 0x00dae12c, 
void (void)* init = 0x00668610) Line: 93, Byte Offsets: 0x68??? C
 ???? <app-name>.exe!OPENSSL_init_crypto(unsigned __int64 opts = 76, 
ossl_init_settings_st* settings = 0x00000000) Line: 678, Byte Offsets: 
0x324??? C
 ???? <app-name>.exe!OPENSSL_init_ssl(unsigned __int64 opts = 76, 
ossl_init_settings_st* settings = 0x00000000) Line: 205, Byte Offsets: 
0xb8??? C
 ??? calling function in main thread.

 ??? Note: Break on exception in CRYPTO_malloc file=(0x00c66c20) 
"crypto\lhash\lhash.c"??? and line : 51

If you've any ideas on what to check/try please let me know.

Config file run:
perl.exe Configure no-idea no-mdc2 no-rc5 no-ssl3 no-weak-ssl-ciphers 
no-async no-engine VC-CE

I've tried to match the compiler and linker flags, including the 
threading flag to main apps /MDd setting
Also I've no idea why configure would add the OPENSSL_PIC preprocessor 
flag so I replaced it with OPENSSL_SYS_WINCE, (Didn't work with 
OPENSSL_PIC set either)
I also removed the L_ENDIAN flag since that wasn't used in our main 
build(Didn't work with L_ENDIAN set either).

---? Manual changes to makefile? ---
- CFLAGS=/W3 /wd4090 /nologo /O1i
+ CFLAGS=/W3 /wd4090 /nologo /Od? /Os -D_MSC_VER=1200 /DEBUG
...
- CNF_CPPFLAGS=-D_WIN32_WCE=420 -DUNDER_CE=420 
-DWCE_PLATFORM_POCKET_PC_2003___ -DARM -D_ARM_ -DARMV4 
-D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" 
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" 
-D"NDEBUG" -I"\$(WCECOMPAT)/include"
+ CNF_CPPFLAGS=-D_WIN32_WCE=420 -DUNDER_CE=420 
-DWCE_PLATFORM_POCKET_PC_2003___ /DEBUG -DARM -D_ARM_ -DARMV4 
-D"OPENSSL_SYS_WINCE" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" 
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"? 
-I"$(WCECOMPAT)/include"
...
- CNF_CFLAGS=/GF /Gy? /MD
+ CNF_CFLAGS=/GF /Gy? /MDd /DEBUG /Od
...
- LIB_CPPFLAGS=-D_WIN32_WCE=420 -DUNDER_CE=420 
-DWCE_PLATFORM_POCKET_PC_2003___ -DARM -D_ARM_ -DARMV4 -D"L_ENDIAN" 
-D"NO_CHMOD" -D"OPENSSL_SMALL_FOOTPRINT" -D"OPENSSL_PIC" 
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-1_1\"" 
$(CNF_CPPFLAGS) $(CPPFLAGS)
+ LIB_CPPFLAGS=-D_WIN32_WCE=420 -DUNDER_CE=420 
-DWCE_PLATFORM_POCKET_PC_2003___ -DARM -D_ARM_ -DARMV4 -D"NO_CHMOD" 
-D"OPENSSL_SMALL_FOOTPRINT" -D"OPENSSL_SYS_WINCE" 
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" 
-D"ENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-1_1\"" 
$(CNF_CPPFLAGS) $(CPPFLAGS)
...
- CPPFLAGS_Q=-D_WIN32_WCE=420 -DUNDER_CE=420 
-DWCE_PLATFORM_POCKET_PC_2003___ -DARM -D_ARM_ -DARMV4 -D"L_ENDIAN" 
-D"NO_CHMOD" -D"OPENSSL_SMALL_FOOTPRINT" -D"OPENSSL_PIC"
+ CPPFLAGS_Q=-D_WIN32_WCE=420 -DUNDER_CE=420 
-DWCE_PLATFORM_POCKET_PC_2003___ -DARM -D_ARM_ -DARMV4 -D"NO_CHMOD" 
-D"OPENSSL_SMALL_FOOTPRINT" -D"OPENSSL_SYS_WINCE"
...
- CNF_LDFLAGS=/subsystem:windowsce,4.20 /machine:ARM
+ CNF_LDFLAGS=/subsystem:windowsce,4.20 /machine:ARM /LARGEADDRESSAWARE 
/ARMPADCODE

--- Visual Studio 2005 Compiler command line copy for main 
application(Uses wxWidgets 2.8.3 and gSoap
Od /Os
/I "C:\third_party\wxwidgets-2.8.3\include"
/I "C:\third_party\Boost\boost_1_33_1"
... other includes
/D "DEBUG" /D "_DEBUG" /D "_WIN32_WCE=0x420" /D "UNDER_CE=0x420" /D 
"WIN32_PLATFORM_PSPC" /D "WINCE" /D "_WINDOWS" /D "ARM" /D "_ARM_" /D 
"__WXWINCE__" /D "__WXDEBUG__" /D "wxNO_EXCEPTIONS" /D "wxNO_RTTI" /D 
"JS_EXPORT_API=1" /D "USE_JS_PARSER=1" /D "_UNICODE" /D "UNICODE"
/FD /EHsc /MDd /Gy /fp:fast /GR- /Yc"wx/wxprec.h"
/Fp"Pocket PC 2003 (ARMV4)\debug/<app-name>.pch" /Fo"Pocket PC 2003 
(ARMV4)\debug/" /Fd"Pocket PC 2003 (ARMV4)\debug/<app-name>.pdb" 
/FR"Pocket PC 2003 (ARMV4)\debug/"
/W4 /nologo /c /Zi /TP



---? OpenSSL 1.1.1b CC command snip
 ??????? cl? /Zi /Fdossl_static.pdb /GF /Gy? /MDd /DEBUG /Od /W3 /wd4090 
/nologo /Od? /Os -D_MSC_VER=1200 /DEBUG /I "." /I "include" 
-D_WIN32_WCE=420 -DUNDER_CE=420 -DWCE_PLATFORM_POCKET_PC_2003___ -DARM 
-D_ARM_ -DARMV4 -D"NO_CHMOD" -D"OPENSSL_SMALL_FOOTPRINT" 
-D"OPENSSL_SYS_WINCE" -D"OPENSSLDIR=\"C:\\Program Files\\Common 
Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program 
Files\\OpenSSL\\lib\\engines-1_1\"" -D_WIN32_WCE=420 -DUNDER_CE=420 
-DWCE_PLATFORM_POCKET_PC_2003___ /DEBUG -DARM -D_ARM_ -DARMV4 
-D"OPENSSL_SYS_WINCE" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" 
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" 
-I""C:\third_party\wcecompat-master"/include"? /Zs /showIncludes 
"ssl\t1_trce.c" 2>&1 > ssl\t1_trce.d
 ??????? cl? /Zi /Fdossl_static.pdb /GF /Gy? /MDd /DEBUG /Od /W3 /wd4090 
/nologo /Od? /Os -D_MSC_VER=1200 /DEBUG /I "." /I "include" 
-D_WIN32_WCE=420 -DUNDER_CE=420 -DWCE_PLATFORM_POCKET_PC_2003___ -DARM 
-D_ARM_ -DARMV4 -D"NO_CHMOD" -D"OPENSSL_SMALL_FOOTPRINT" 
-D"OPENSSL_SYS_WINCE" -D"OPENSSLDIR=\"C:\\Program Files\\Common 
Files\\SSL\"" -D"ENGINESDIR=\"C:\\Program 
Files\\OpenSSL\\lib\\engines-1_1\"" -D_WIN32_WCE=420 -DUNDER_CE=420 
-DWCE_PLATFORM_POCKET_PC_2003___ /DEBUG -DARM -D_ARM_ -DARMV4 
-D"OPENSSL_SYS_WINCE" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" 
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" 
-I""C:\third_party\wcecompat-master"/include"? -c /Fossl\tls13_enc.obj 
"ssl\tls13_enc.c"
tls13_enc.c
include\internal/refcount.h(111) : warning C4028: formal parameter 1 
different from declaration



Thanks
Jim


From dfulger at gmx.com  Tue Apr 30 07:14:53 2019
From: dfulger at gmx.com (Dan Fulger)
Date: Tue, 30 Apr 2019 09:14:53 +0200
Subject: An idiosyncratic port of OpenSSL 1.1.1b to OS/400 ILE
Message-ID: <trinity-10717e4e-20ce-4f2c-b0a3-6ea9f9d4739b-1556608493138@3c-app-mailcom-bs13>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190430/2c61638c/attachment.html>

From levitte at openssl.org  Tue Apr 30 08:04:41 2019
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 30 Apr 2019 10:04:41 +0200
Subject: Where to copy custom openssl engine library in openssl 1.1.0
In-Reply-To: <HE1PR0602MB3643CE7AE9FACA4835653DB8963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
References: <HE1PR0602MB3643CE7AE9FACA4835653DB8963D0@HE1PR0602MB3643.eurprd06.prod.outlook.com>
Message-ID: <878svrsyue.wl-levitte@openssl.org>

You can ask the openssl app where it goes looking for engines by
default.  Here's what it looks like with the installed openssl on my
machine:

    : ; openssl version -e
    ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"

Note that engines aren't agnostic to the OpenSSL version...

Cheers,
Richard

On Thu, 25 Apr 2019 10:06:53 +0200,
Swamy J-S wrote:
> 
> 
> Am working in Ubuntu 18.04 with openssl 1.1.0g version. I built a custom openssl engine and now i
> want to use this engine instead of default openssl engine.
> 
> My engine library name is libstoreengine.so and i copied this to /usr/lib/x86_64-linux-gnu/
> openssl-1.0.0/engines/ path.
> 
> When i run my application the it says Store Engine not found. There is path issue here, am i
> copying the library in right path? I copied my library in /lib/x86_64-linux-gnu still am getting
> same error.
> 
> Please let me know the right path where i have to copy this engine?
> 
> Thanks and Regards,
> 
> SWAMY J S
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From felipe at felipegasper.com  Tue Apr 30 15:06:04 2019
From: felipe at felipegasper.com (Felipe Gasper)
Date: Tue, 30 Apr 2019 11:06:04 -0400
Subject: partial SSL_read()
Message-ID: <77C8C481-F94F-43B3-8F6F-FE73C33A1E13@felipegasper.com>

Hello,

	I?ve got an OpenSSL client that?s showing the behavior in strace:

read 5 bytes - OK
read 11228 bytes - gets partial response
read remainder - ECONNRESET

	That ECONNRESET causes OpenSSL to fail the entire SSL_read().

	My question is, does TLS allow a client to be _able_ to parse an incomplete message? Or is it that only the entire message can be decoded?

	Thank you!

-Felipe Gasper
Mississauga, Ontario

From Michael.Wojcik at microfocus.com  Tue Apr 30 16:21:51 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 30 Apr 2019 16:21:51 +0000
Subject: partial SSL_read()
In-Reply-To: <77C8C481-F94F-43B3-8F6F-FE73C33A1E13@felipegasper.com>
References: <77C8C481-F94F-43B3-8F6F-FE73C33A1E13@felipegasper.com>
Message-ID: <BYAPR18MB291880F7047053371D7B8EF4F93A0@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Felipe Gasper <felipe at felipegasper.com>
> Sent: Tuesday, April 30, 2019 11:06

> My question is, does TLS allow a client to be _able_ to parse an incomplete message?
> Or is it that only the entire  message can be decoded?

TLS doesn't have the concept of a "message". It has records. Application data from the peer may occupy one or more records.

If a record can't be received completely, while it might be possible to decrypt the partial content (or, depending on cipher type and chaining mode, all but the last cipher block received), it wouldn't be possible to authenticate the data. Thus you'd fall prey to Moxie Marlinspike's Cryptography Doom Principle. Except in unusual circumstances (e.g. attacking the peer, or forensics) you Don't Want To Do That.

Consider that if you're using a stream cipher, or a block cipher in a streaming mode such as GCM, that an attacker can 1) tamper with the application data in a record by bit-flipping, then 2) abort the conversation by forging an RST or similar, cutting the tampered block short. If the receiver attempts to act on the data in the partial block, the attack succeeds.

Even just attempting to decrypt and log the partial data could be dangerous, for example if the log is later displayed using a web-based tool that has an XSS vulnerability, or some sort of binary parser with an exploitable overflow (e.g. a buggy Wireshark dissector).

-- 
Michael Wojcik

From felipe at felipegasper.com  Tue Apr 30 16:35:49 2019
From: felipe at felipegasper.com (Felipe Gasper)
Date: Tue, 30 Apr 2019 12:35:49 -0400
Subject: partial SSL_read()
In-Reply-To: <BYAPR18MB291880F7047053371D7B8EF4F93A0@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <77C8C481-F94F-43B3-8F6F-FE73C33A1E13@felipegasper.com>
 <BYAPR18MB291880F7047053371D7B8EF4F93A0@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <EB6FD366-36A9-4EC4-90CF-9EA83F009A8A@felipegasper.com>



> On Apr 30, 2019, at 12:21 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
>> From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Felipe Gasper <felipe at felipegasper.com>
>> Sent: Tuesday, April 30, 2019 11:06
> 
>> My question is, does TLS allow a client to be _able_ to parse an incomplete message?
>> Or is it that only the entire  message can be decoded?
> 
> TLS doesn't have the concept of a "message". It has records. Application data from the peer may occupy one or more records.
> 
> If a record can't be received completely, while it might be possible to decrypt the partial content (or, depending on cipher type and chaining mode, all but the last cipher block received), it wouldn't be possible to authenticate the data. Thus you'd fall prey to Moxie Marlinspike's Cryptography Doom Principle. Except in unusual circumstances (e.g. attacking the peer, or forensics) you Don't Want To Do That.
> 
> Consider that if you're using a stream cipher, or a block cipher in a streaming mode such as GCM, that an attacker can 1) tamper with the application data in a record by bit-flipping, then 2) abort the conversation by forging an RST or similar, cutting the tampered block short. If the receiver attempts to act on the data in the partial block, the attack succeeds.
> 
> Even just attempting to decrypt and log the partial data could be dangerous, for example if the log is later displayed using a web-based tool that has an XSS vulnerability, or some sort of binary parser with an exploitable overflow (e.g. a buggy Wireshark dissector).

Ah, ok, that makes sense. Thank you for your response!

-FG

From Michael.Wojcik at microfocus.com  Tue Apr 30 16:31:03 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 30 Apr 2019 16:31:03 +0000
Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
In-Reply-To: <DM6PR07MB4650148D8EE6592229C38A83F5390@DM6PR07MB4650.namprd07.prod.outlook.com>
References: <DM6PR07MB4650148D8EE6592229C38A83F5390@DM6PR07MB4650.namprd07.prod.outlook.com>
Message-ID: <BYAPR18MB29184DA92B59D46BCE7077E6F93A0@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users <openssl-users-bounces at openssl.org> on behalf of John Unsworth <John.Unsworth at synchronoss.com>
> Sent: Monday, April 29, 2019 10:54

> We are using OpenSSL 1.1.0h on Linux to send operations to LDAP servers. We use SSL_read()
> to receive the replies on a non-blocking socket. The vast majority of times SSL_read()  returns >0,
> SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE as per the spec. However we are very
> occasionally seeing SSL_ERROR_SYSCALL with errno 11 (EAGAIN) which would seem to be the
> result of a platform socket read(() or write() when blocking would occur. Is this expected
> behaviour? We have changed our code to treat this as SSL_ERROR_WANT_READ or
> SSL_WANT_WRITE depending on the result of SSL_want_write(). Are we correct?
?
I haven't seen a reply to this, so I'll take a stab...

I haven't looked at the code, but my impression is that WANT_READ and WANT_WRITE are returned in two cases: when OpenSSL has received or sent a partial record and needs to complete it; or when the TLS state is such that OpenSSL needs to perform the associated operation and it hasn't been requested by the application - for example, if the application is trying to receive data but OpenSSL needs to send renegotiation information.

If you do a non-blocking receive at a record boundary (so you don't have an incomplete record) and OpenSSL doesn't currently need to send for TLS reasons, OpenSSL will see the EAGAIN (or EWOULDBLOCK, depending on platform). I think in this case it does just return SSL_ERROR_SYSCALL, because OpenSSL itself doesn't "want" to receive. If OpenSSL had already received a partial record, then you'd get WANT_READ.

I suspect you could always treat this as WANT_READ, which typically means using a mechanism such as select or poll to determine when the socket is readable, then trying the OpenSSL receive again. But looking at the return value of SSL_want_write() seems safe enough.

That's my understanding. Someone else may know better.

-- 
Michael Wojcik

From openssl-users at dukhovni.org  Tue Apr 30 17:18:36 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 30 Apr 2019 13:18:36 -0400
Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
In-Reply-To: <BYAPR18MB29184DA92B59D46BCE7077E6F93A0@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <DM6PR07MB4650148D8EE6592229C38A83F5390@DM6PR07MB4650.namprd07.prod.outlook.com>
 <BYAPR18MB29184DA92B59D46BCE7077E6F93A0@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <60444857-0C8A-41AB-B5C2-50B62DF75EDC@dukhovni.org>

> On Apr 30, 2019, at 12:31 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
> I haven't seen a reply to this, so I'll take a stab...
> 
> I haven't looked at the code, but my impression is that WANT_READ and WANT_WRITE are returned in two cases: when OpenSSL has received or sent a partial record and needs to complete it; or when the TLS state is such that OpenSSL needs to perform the associated operation and it hasn't been requested by the application - for example, if the application is trying to receive data but OpenSSL needs to send renegotiation information.
> 
> If you do a non-blocking receive at a record boundary (so you don't have an incomplete record) and OpenSSL doesn't currently need to send for TLS reasons, OpenSSL will see the EAGAIN (or EWOULDBLOCK, depending on platform). I think in this case it does just return SSL_ERROR_SYSCALL, because OpenSSL itself doesn't "want" to receive. If OpenSSL had already received a partial record, then you'd get WANT_READ.

I think the above guess is not correct.  A cursory look at the
code suggests that even user-initiated reads normally return
SSL_ERROR_WANT_READ when the network bio signals a retriable
failure.

The OP has not provided much detail about the connections in
question are created.  Is the connection made by the
application, and SSL negotiated over an existing socket, or
is the connection established by OpenSSL over a "connect bio"?

Is the handshake explicit, or does the application just call
SSL_read(), with OpenSSL performing the handshake as needed?

In any case, I would not expect SSL_ERROR_SYSCALL under normal
conditions.  The documentation says:

       SSL_ERROR_SYSCALL
           Some non-recoverable, fatal I/O error occurred. The OpenSSL error
           queue may contain more information on the error. For socket I/O on
           Unix systems, consult errno for details. If this error occurs then
           no further I/O operations should be performed on the connection and
           SSL_shutdown() must not be called.

           This value can also be returned for other errors, check the error
           queue for details.

-- 
	Viktor.


From erik at efca.com  Tue Apr 30 22:23:23 2019
From: erik at efca.com (Erik Forsberg)
Date: Tue, 30 Apr 2019 15:23:23 -0700
Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
In-Reply-To: <60444857-0C8A-41AB-B5C2-50B62DF75EDC@dukhovni.org>
References: <60444857-0C8A-41AB-B5C2-50B62DF75EDC@dukhovni.org>
Message-ID: <4eTWI5Vk5QBXoM1@srv.efca.com>

I can add some of my own observations to this below ...

>> I haven't looked at the code, but my impression is that WANT_READ and WANT_WRITE are returned in two cases: when OpenSSL has received or sent a partial record and needs to complete it; or when the TLS state is such that OpenSSL needs to perform the associated operation and it hasn't been requested by the application - for example, if the application is trying to receive data but OpenSSL needs to send renegotiation information.
>> 
>> If you do a non-blocking receive at a record boundary (so you don't have an incomplete record) and OpenSSL doesn't currently need to send for TLS reasons, OpenSSL will see the EAGAIN (or EWOULDBLOCK, depending on platform). I think in this case it does just return SSL_ERROR_SYSCALL, because OpenSSL itself doesn't "want" to receive. If OpenSSL had already received a partial record, then you'd get WANT_READ.
>
>I think the above guess is not correct.  A cursory look at the
>code suggests that even user-initiated reads normally return
>SSL_ERROR_WANT_READ when the network bio signals a retriable
>failure.
>
>The OP has not provided much detail about the connections in
>question are created.  Is the connection made by the
>application, and SSL negotiated over an existing socket, or
>is the connection established by OpenSSL over a "connect bio"?
>
>Is the handshake explicit, or does the application just call
>SSL_read(), with OpenSSL performing the handshake as needed?
>

I occasionally (somewhat rarely) see the issue mentioned by the OP.
Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE
does effectively hides the issue and connection works fine. I predominantly
run on Solaris 11. In my case, I open the socket myself, set non-blocking
mode and associates with an SSL object using SS_set_fd().
The initial handshake is done explicitly.



From openssl-users at dukhovni.org  Tue Apr 30 22:37:04 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 30 Apr 2019 18:37:04 -0400
Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
In-Reply-To: <4eTWI5Vk5QBXoM1@srv.efca.com>
References: <60444857-0C8A-41AB-B5C2-50B62DF75EDC@dukhovni.org>
 <4eTWI5Vk5QBXoM1@srv.efca.com>
Message-ID: <20190430223704.GA67454@straasha.imrryr.org>

On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote:

> >Is the handshake explicit, or does the application just call
> >SSL_read(), with OpenSSL performing the handshake as needed?
> 
> I occasionally (somewhat rarely) see the issue mentioned by the OP.
> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE
> does effectively hides the issue and connection works fine. I predominantly
> run on Solaris 11. In my case, I open the socket myself, set non-blocking
> mode and associates with an SSL object using SS_set_fd().
> The initial handshake is done explicitly.

Recoverable errors should not result in SSL_ERROR_SYSCALL.  This
feels like a bug.  I'd like to hear from Matt Caswell on this one.
Perhaps someone should open an issue on Github...

-- 
	Viktor.

From erik at efca.com  Tue Apr 30 22:41:59 2019
From: erik at efca.com (Erik Forsberg)
Date: Tue, 30 Apr 2019 15:41:59 -0700
Subject: SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN
In-Reply-To: <20190430223704.GA67454@straasha.imrryr.org>
References: <20190430223704.GA67454@straasha.imrryr.org>
Message-ID: <dHKCjOmyehtRcE6@srv.efca.com>


>-- Original Message --
>
>On Tue, Apr 30, 2019 at 03:23:23PM -0700, Erik Forsberg wrote:
>
>> >Is the handshake explicit, or does the application just call
>> >SSL_read(), with OpenSSL performing the handshake as needed?
>> 
>> I occasionally (somewhat rarely) see the issue mentioned by the OP.
>> Ignoring the error, or mapping it and do what WANT_READ/WANT_WRITE
>> does effectively hides the issue and connection works fine. I predominantly
>> run on Solaris 11. In my case, I open the socket myself, set non-blocking
>> mode and associates with an SSL object using SS_set_fd().
>> The initial handshake is done explicitly.
>
>Recoverable errors should not result in SSL_ERROR_SYSCALL.  This
>feels like a bug.  I'd like to hear from Matt Caswell on this one.
>Perhaps someone should open an issue on Github...
>
I will scan my logs later this evening and see if this is still an issue.
Last time I remember seeing it was quote some long time ago (couple of years)