Re: Replacement for CRYPTO_thread_id() & ERR_get_error_line_data() for openssl3.0

[Matt Caswell]

On 03/09/2021 05:58, Shivakumar Poojari wrote:

Hi All,

We are upgrading our code to openssl 3.0. the below function we trying 
to replace, searched in the openssl man pages not found proper information.


CRYPTO_thread_id()


The deprecated implementation of this is a no-op (always returns 0). 
What do you need this for? This used to be useful when locking callbacks 
existed. But they were removed in 1.1.0.




ERR_get_error_line_data()


You can call ERR_get_error_all() as a replacement (passing a NULL value 
for the "func" parameter).



Matt




please suggest.
thanks,
shivakumar.


Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others or 
forwarding without express permission is strictly prohibited. If you are 
not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.

Re: How to get rsa-private key in plain text format?

[Matt Caswell]

On 03/09/2021 00:21, Shariful Alam wrote:

Hello,
Is there any command-line tool to get the plain text rsa private key 
like the following format from .pem file?


openssl rsa -in mykey.pem -noout -text

Matt

Re: What to replace low-level padding operations with in OSSL 3.0?

[Matt Caswell]

On 02/09/2021 22:47, William Roberts wrote:

I have code that applies PCKS1.5 padding via
RSA_padding_add_PKCS1_type_1 and strips it with
RSA_padding_check_PKCS1_type_2 before sending it to the HSM for raw
RSA operation to support a legacy PKCS11 interface. Is there any way
to perform these tasks with OpenSSL 3.0?


No, there is no non-deprecated way to do this in OpenSSL 3.0. Those 
functions still *exist* and you may still call them, but they are 
deprecated.


Matt

Re: Question about constness of EVP_PKEY* arguments in public API

[Matt Caswell]

On 02/09/2021 16:43, Romain GEISSLER via openssl-users wrote:

I am using the following OpenSSL API: EVP_DigestSignInit,
EVP_DigestVerifyInit, EVP_PKEY_size, EVP_SealInit, EVP_OpenInit. And
it seems these all take an non-const EVP_PKEY* argument. Does it mean
that EVP_PKEY* have some internal state which may be updated by these
API and which I should definitely not call without thread
syncronization in multiple threads ? Or the API of OpenSSL just miss
the "const" keyword as really the key, once read, has absolutely no
state modified by these APIs ?


Neither of the above. EVP_PKEY has internal state which may be modified 
by these API calls. However that internal state is controlled by an 
internal lock and is therefore thread safe.


Matt

Re: client authentication status

[Matt Caswell]

On 01/09/2021 16:36, Zeke Evans wrote:
Is there any way to check the status of client authentication sent in a 
TLS 1.3 handshake after SSL_connect returns?  With TLS 1.2 SSL_connect 
seems to always capture the status and return an error code if it failed 
but not TLS 1.3.  I haven’t been able to find a good way to do this 
after SSL_connect returns.  I have to handle blocking and non-blocking 
sockets so calling SSL_read or SSL_peek isn’t an option since those 
could block.  If client authentication happened to fail then calling 
those methods would work because they will return an error but if it 
didn’t fail then they could block.


At a protocol level the handshake looks like this:

   Client   Server

Key  ^ ClientHello
Exch | + key_share*
 | + signature_algorithms*
 | + psk_key_exchange_modes*
 v + pre_shared_key*   >
  ServerHello  ^ Key
 + key_share*  | Exch
+ pre_shared_key*  v
{EncryptedExtensions}  ^  Server
{CertificateRequest*}  v  Params
   {Certificate*}  ^
 {CertificateVerify*}  | Auth
   {Finished}  v
   <  [Application Data*]
 ^ {Certificate*}
Auth | {CertificateVerify*}
 v {Finished}  >
   [Application Data]  <--->  [Application Data]


The handshake has completed from the perspective of one of the endpoints 
once it has both sent and received a "Finished" message.


From the above you can see that the client receives the server's 
"Finished" message before it sends its "Certificate"/"CertificateVerify" 
and "Finished" messages back to the server. At this point "SSL_connect" 
returns and the client is ready to start receiving application data.


From the server's perspective it is still handshaking when it receives 
the client's certificate (because it didn't receive the client's 
"Finished" message yet). So the server when send an alert at this point 
if the certificate is not acceptable and SSL_accept() will return with a 
failure.


The client does not know what it will receive back from the server. It 
could either be application data (in the case of an accepted 
certificate) or an alert (in the case of a reject certificate). The only 
way it can find out is to attempt to read data from the connection and 
see what it gets back. The API to do this is SSL_read()/SSL_peek().


So, to answer your question, there is no way to check the status of 
client authentication without calling SSL_read()/SSL_peek(). It 
necessarily requires an attempt to read data from the socket in order to 
find that status out due to the way the protocol is designed.



On 01/09/2021 16:51, Benjamin Kaduk via openssl-users wrote:
> Note that the server is allowed to ignore a client cert that it 
doesn't like, proceeding with the connection as if the client was 
unauthenticated.  If you need a specific signal that the server believes 
the client successfully authenticated, that has to be at the application 
layer.


This is true, but ultimately the client still needs to attempt to read 
data from the socket to figure out what the server did.


> Did you try a zero-length SSL_read()?  My recollection is that that 
gets far enough into the library to see if there are pending alert 
messages to process.


Again, there will only be alerts to process (related to a client 
certificate failure) if the client has attempted to read application data.


Matt

Re: Consultation:Additional “ephemeral public key” and “ephemeral private key" implementations for quictls/opens

[Matt Caswell]

On 29/08/2021 20:41, Nobuo Aoki wrote:

I am trying to identify the implementation
where “ephemeral public key” and “ephemeral private key” can be added,


I am unclear from your question whether you are asking how to add a new 
public/private key scheme for integration into TLS. Or whether you are 
simply asking for the location in the code where the key_share is 
generated. If the latter then you might look here for the client side:


https://github.com/openssl/openssl/blob/e8e1f6d1a9e599d575431f559200018b8f822e0f/ssl/statem/extensions_clnt.c#L649-L705

And here for the server side:

https://github.com/openssl/openssl/blob/e8e1f6d1a9e599d575431f559200018b8f822e0f/ssl/statem/extensions_srvr.c#L1577-L1707


Matt

Re: How to get "EVP_PKEY *dhpkey" from NID_X9_62_prime256v1.

[Matt Caswell]

On 27/08/2021 08:47, Kumar Mishra, Sanjeev wrote:

Hi All,
I am upgrading the code from OpenSSL 1.0.1 to OpenSSL 3.0.
I am getting compilation errors for deprecated functions and structure 
like "EC_KEY_new_by_curve_name()" , "SSL_CTX_set_tmp_ecdh()" and 
"EC_KEY"..etc.


The code is like follows --
---
---
EC_KEY *ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
SSL_CTX_set_tmp_ecdh(mrmIcbPtr -> sslServerCtx, ecdh);
.
.


The SSL_CTX_set_tmp_ecdh man page says this:

"SSL_CTX_set_tmp_ecdh() sets ECDH parameters to be used to be B.
The key is inherited by all B objects created from B.
This macro is deprecated in favor of L."

https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_tmp_ecdh.html

So call SSL_CTX_set1_groups() instead:

https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html

Actually, even easier you can call SSL_CTX_set1_groups_list() 
(documented on the same man page), which means you can just set the 
group via a string:


SSL_CTX_set1_groups_list(mrmIcbPtr -> sslServerCtx, "P-256");

Where "P-256" is the string name associated with NID_X9_62_prime256v1.

Or your final alternative is to not doing anything at all, and simply 
remove this code. In 3.0 you can specify multiple groups and they have 
sensible defaults that are already set for you (which include X25519 and 
P-256).


Matt

OpenSSL Security Advisory

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [24 August 2021]
==

SM2 Decryption Buffer Overflow (CVE-2021-3711)
==

Severity: High

In order to decrypt SM2 encrypted data an application is expected to call the
API function EVP_PKEY_decrypt(). Typically an application will call this
function twice. The first time, on entry, the "out" parameter can be NULL and,
on exit, the "outlen" parameter is populated with the buffer size required to
hold the decrypted plaintext. The application can then allocate a sufficiently
sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL
value for the "out" parameter.

A bug in the implementation of the SM2 decryption code means that the
calculation of the buffer size required to hold the plaintext returned by the
first call to EVP_PKEY_decrypt() can be smaller than the actual size required by
the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is
called by the application a second time with a buffer that is too small.

A malicious attacker who is able present SM2 content for decryption to an
application could cause attacker chosen data to overflow the buffer by up to a
maximum of 62 bytes altering the contents of other data held after the
buffer, possibly changing application behaviour or causing the application to
crash. The location of the buffer is application dependent but is typically
heap allocated.

OpenSSL versions 1.1.1k and below are affected by this issue. Users of these
versions should upgrade to OpenSSL 1.1.1l.

OpenSSL 1.0.2 is not impacted by this issue.

OpenSSL 3.0 alpha/beta releases are also affected but this issue will be
addressed before the final release.

This issue was reported to OpenSSL on 12th August 2021 by John Ouyang. The fix
was developed by Matt Caswell.

Read buffer overruns processing ASN.1 strings (CVE-2021-3712)
=

Severity: Moderate

ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING
structure which contains a buffer holding the string data and a field holding
the buffer length. This contrasts with normal C strings which are repesented as
a buffer for the string data which is terminated with a NUL (0) byte.

Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's
own "d2i" functions (and other similar parsing functions) as well as any string
whose value has been set with the ASN1_STRING_set() function will additionally
NUL terminate the byte array in the ASN1_STRING structure.

However, it is possible for applications to directly construct valid ASN1_STRING
structures which do not NUL terminate the byte array by directly setting the
"data" and "length" fields in the ASN1_STRING array. This can also happen by
using the ASN1_STRING_set0() function.

Numerous OpenSSL functions that print ASN.1 data have been found to assume that
the ASN1_STRING byte array will be NUL terminated, even though this is not
guaranteed for strings that have been directly constructed. Where an application
requests an ASN.1 structure to be printed, and where that ASN.1 structure
contains ASN1_STRINGs that have been directly constructed by the application
without NUL terminating the "data" field, then a read buffer overrun can occur.

The same thing can also occur during name constraints processing of certificates
(for example if a certificate has been directly constructed by the application
instead of loading it via the OpenSSL parsing functions, and the certificate
contains non NUL terminated ASN1_STRING structures). It can also occur in the
X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions.

If a malicious actor can cause an application to directly construct an
ASN1_STRING and then process it through one of the affected OpenSSL functions
then this issue could be hit. This might result in a crash (causing a Denial of
Service attack). It could also result in the disclosure of private memory
contents (such as private keys, or sensitive plaintext).

OpenSSL versions 1.1.1k and below are affected by this issue. Users of these
versions should upgrade to OpenSSL 1.1.1l.

OpenSSL versions 1.0.2y and below are affected by this issue. However OpenSSL
1.0.2 is out of support and no longer receiving public updates. Premium support
customers of OpenSSL 1.0.2 should upgrade to 1.0.2za. Other users should upgrade
to 1.1.1l.

An initial instance of this issue in the X509_aux_print() function was reported
to OpenSSL on 18th July 2021 by Ingo Schwarze. The bugfix was developed by Ingo
Schwarze and first publicly released in OpenBSD-current on 10th July 2021 and
subsequently in OpenSSL on 20th July 2021 (commit d9d838ddc). Subsequent
analysis by David Benjamin on 17th August 2021 identified more instances of the

OpenSSL version 1.1.1l published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 1.1.1l released
   ===

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

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1l of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

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

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

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

   The distribution file name is:

o openssl-1.1.1l.tar.gz
  Size: 9834044
  SHA1 checksum: f8819dd31642eebea6cc1fa5c256fc9a4f40809b
  SHA256 checksum: 
0b7a3e5e59c34827fe0c3a74b7ec8baef302b98fa80088d7f9153aa16fa76bd1

   The checksums were calculated using the following commands:

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

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmEk9nQACgkQ2cTSbQ5g
RJFk2QgAr9NfJzaDqFFDnjCS7bCGyOf77I4P7IFKfD2Ip4BFYUAS//x7rHjyBs/+
LvbXGm1uht8QWvqA+j6jgq/FwHJS0NhYiw8JPh9E/ATqjhx0K3Pe133u8oy4KOWL
/yZvc7bm99Fh9kTb+41hYRYqDcnnLvTyjhMT8zTtuZiva3/152zXgSSfbglF9/A5
nnvWRqJMtGX058EuGNpprHT+1HMN/yUr9lkpKR4iHqHTPm/Y+UgQFnwyJnEUDIy3
1yEFiU6FRGyqZL+lLWmv0mORwJRbgFyk1016xMtvR3NsPWITyt9XlkWwExC9mDlG
reN5SLCrLyA9mUVzED6ARSMQNINDbg==
=hKcH
-END PGP SIGNATURE-

Re: 3.0.0. IMPLEMENT_ASN1_FUNCTIONS missing _it prototypes

[Matt Caswell]

On 23/08/2021 20:42, Ken Goldman wrote:
I get warnings on all my ASN1_SEQUENCE_END, a missing prototype for the 
_it functions.

The code is working, but I'd like a clean compile.

3.0.0 only, 1.0.2 and 1.1.1 are OK.

Example:

#include 
#include 
#include 
#include 

typedef struct {
     ASN1_TIME *notBefore;
     ASN1_TIME *notAfter;
} TPM_PARTIAL_CERT_VALIDITY;

ASN1_SEQUENCE(TPM_PARTIAL_CERT_VALIDITY) = {
     ASN1_SIMPLE(TPM_PARTIAL_CERT_VALIDITY, notBefore, ASN1_TIME),
     ASN1_SIMPLE(TPM_PARTIAL_CERT_VALIDITY, notAfter, ASN1_TIME),
} ASN1_SEQUENCE_END(TPM_PARTIAL_CERT_VALIDITY)     line 97 is here


Change this line to:

} static_ASN1_SEQUENCE_END(TPM_PARTIAL_CERT_VALIDITY)

Matt

Forthcoming OpenSSL release

[Matt Caswell]

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL version 1.1.1l.

This release will be made available on Tuesday 24th August 2021
between 1200-1600 UTC.

OpenSSL 1.1.1l is a security-fix release. The highest severity issue
fixed in this release is HIGH:
https://www.openssl.org/policies/secpolicy.html#high

Note that due to this also affecting OpenSSL 3.0 beta releases, OpenSSL 
3.0 final will not be occurring this week.


Yours

The OpenSSL Project Team



OpenPGP_signature
Description: OpenPGP digital signature

Re: IMPLEMENT_ASN1_FUNCTIONS tutorial or help

[Matt Caswell]

On 16/08/2021 21:56, Ken Goldman wrote:
I am trying to parse some ASN.1 DER so I can add it to an X.509 
certificate.


For the input side, a poster showed me

ASN1_SEQUENCE, ASN1_SEQUENCE_END, and then
DECLARE_ASN1_FUNCTIONS, IMPLEMENT_ASN1_FUNCTIONS

which created the i2d() function.


It should also give you the d2i() function too!




Now I would like to do the other end, where I have der and I
want to parse back to the structure, using d2i()

1 - Is there a tutorial on this?


Seems like you don't need one. If you got i2d working you should have 
d2i already!


Matt




2 - Can someone show me this structure?

The DER is a version, serial number, signature algorithm,
public key algorithm, and public key.

The dump looks like this:

  0 337: SEQUENCE {
   4   3: . [0] {
   6   1: . . INTEGER 2
    : . . }
   9  21: . INTEGER 00 87 12 50 78 0A C9 8B 60 DD AC FA 75 18 05 EC DC 
30 51 53 23

  32  13: . SEQUENCE {
  34   9: . . OBJECT IDENTIFIER sha256WithRSAEncryption (1 2 840 113549 
1 1 11)

    : . . . (PKCS #1)
  45   0: . . NULL
    : . . }
  47 290: . SEQUENCE {
  51  13: . . SEQUENCE {
  53   9: . . . OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
    : . . . . (PKCS #1)
  64   0: . . . NULL
    : . . . }
  66 271: . . BIT STRING, encapsulates {
  71 266: . . . SEQUENCE {
  75 257: . . . . INTEGER
    : . . . . . 00 B0 83 4A E9 41 78 E0 6A C3 0F D6 E4 B9 7D 96
    : . . . . . 70 74 05 00 C9 E2 2C 6C 4C 6E 16 02 40 5C 35 29
    : . . . . . F6 EF 9F 55 3A BD 4B 74 1D 6A 21 38 20 69 C8 88
    : . . . . . A3 6B 56 62 2A 91 02 41 58 92 97 87 19 1C AD 19
    : . . . . . 53 56 FB 7E 9D 86 B8 4E 8D 82 6A 87 A7 93 55 8F
    : . . . . . AB E8 89 D7 63 0B C9 02 99 D8 37 F8 FB 6B 32 98
    : . . . . . 6A 05 3F 9E 22 B6 D3 6F BB BE 2D AC 6C 74 17 5D
    : . . . . . 15 EE 84 E5 A4 8F 9C C3 83 CD 83 81 63 EC B5 85
    : . . . . . 6B 1A B8 57 80 2C ED E3 A7 F2 8C F7 3F 13 D9 27
    : . . . . . 2E 64 37 49 E6 47 8E 0A 11 64 46 72 DD F9 EB 4F
    : . . . . . B8 13 58 0B 47 F7 72 AB 29 D6 A5 05 44 30 E7 8D
    : . . . . . FE 86 8A E8 5F 10 91 13 04 57 47 96 A7 97 28 3C
    : . . . . . 39 BD 23 3F C6 41 5E 45 3F A5 41 F5 BF 7D C2 7C
    : . . . . . CC F9 97 20 3F 20 82 AF 64 8C BC 0D 99 F4 BA 10
    : . . . . . 53 58 C5 EC 86 DE 26 ED D9 D6 F2 60 49 C9 E7 9B
    : . . . . . 6A 64 D2 BC C5 0E B0 1D EB 45 43 89 A6 4E 64 B4
    : . . . . . A1
336   3: . . . . INTEGER 65537
    : . . . . }
    : . . . }
    : . . }
    : . }

Re: Crash seen in OPENSSL_sk_pop_free

[Matt Caswell]

On 13/08/2021 17:31, Bala Duvvuri via openssl-users wrote:

Hi All,

We are using OpenSSl version 1.1.1d in our program and crash is being seen in 
"OPENSSL_sk_pop_free" API, we invoke this API in our certificate verification 
API. Since crash is not seen always, trying to understand from OpenSSL code, when can 
this occur?


My first suspicion would be a double-free, i.e. calling a free routine 
on data that has already been freed. You might like to compile OpenSSL 
and your application with asan (use the enable-asan compile time 
Configure option for OpenSSL) and see if anything shows up.


Matt



Below is the bt of the crash

#0  0x0f31f438 in OPENSSL_sk_pop_free (st=0x1041de20, func=0xf34d5b0 
) at crypto/stack/stack.c:367
 i = 0
#1  0x0f344c74 in sk_X509_pop_free (freefunc=, sk=) at include/openssl/x509.h:99
No locals.
#2  X509_STORE_CTX_cleanup (ctx=ctx@entry=0x1041ba70) at 
crypto/x509/x509_vfy.c:2454
No locals.
#3  0x0f344cf4 in X509_STORE_CTX_free (ctx=ctx@entry=0x1041ba70) at 
crypto/x509/x509_vfy.c:2281
No locals


Below is the OpenSSL API

360 void OPENSSL_sk_pop_free(OPENSSL_STACK *st, OPENSSL_sk_freefunc func)
361 {
362 int i;
363
364 if (st == NULL)
365 return;
366 for (i = 0; i < st->num; i++)
367 if (st->data[i] != NULL)-> Crash seen here
368 func((char *)st->data[i]);
369 OPENSSL_sk_free(st);
370 }

Can someone please help to understand under what conditions this can happen?

We use the below API's during certificate verification:

X509_STORE_new()
X509_STORE_CTX_new()
X509_STORE_set_verify_cb_func
X509_STORE_set_default_paths
X509_STORE_load_locations
X509_STORE_CTX_init
X509_STORE_CTX_set_flags
X509_verify_cert

/* Cleanup. */
FREE_X509_STORE_CTX(pContext);

Thanks
Bala

Re: OpenSSL beta testing on Solaris and z/OS

[Matt Caswell]

On 12/08/2021 01:35, Dennis Clarke via openssl-users wrote:

On 8/5/21 00:55, Dr Paul Dale wrote:

Dennis,

Thanks for the information.  Solaris and z/OS are not tested by the
project, so it's good to know they aren't too far from working out of
the box.

We would definitely be interested in a pull request with your fixes at
some stage -- post 3.0 since it's almost certainly too late now.



 I thought we were still in "beta" testing mode here?


Release of 3.0 "final" is imminent. OTC met on Tuesday 10th to decide 
whether to release it today (Thursday 12th) or not. Ultimately they 
decided not to, but will review again next Tuesday.


Matt

Re: EVP_MAX_BLOCK_LENGTH Macro for upgrading application from openssl 1.0.2 to openssl 3.0

[Matt Caswell]

On 11/08/2021 08:16, Paramashivaiah, Sunil wrote:

Hi All,

In our application we are using  MD5_CBLOCK, SHA_CBLOCK, SHA256_CBLOCK, 
SHA512_CBLOCK macros which are deprecated in openssl 3.0.


   We are trying upgrade our application from using openssl 
1.0.2 to openssl 3.0.


  Can we use EVP_MAX_BLOCK_LENGTH to replace all these 
macros. Please suggest.


No, these things are not equivalent. EVP_MAX_BLOCK_LENGTH is referring 
to the block size for ciphers. Why do you need the block size for the 
digests?


You can query the block size for a given digest at runtime using 
EVP_MD_get_block_size().


Matt




Thanks and Regards,

Sunil


Notice: This e-mail together with any attachments may contain 
information of Ribbon Communications Inc. and its Affiliates that is 
confidential and/or proprietary for the sole use of the intended 
recipient. Any review, disclosure, reliance or distribution by others or 
forwarding without express permission is strictly prohibited. If you are 
not the intended recipient, please notify the sender immediately and 
then delete all copies, including any attachments.

Re: EVP_MD_CTX_free documentation

[Matt Caswell]

All our _free functions will accept NULL. We rely on this extensively 
*everywhere*. We perhaps could be better at documenting it, but you can 
rely on it.


Matt

On 30/07/2021 17:55, Ken Goldman wrote:

It would be nice if the documentation would guarantee that
this function is a no-op when the parameter is NULL - like
the standard free() call.

This would save coding (if not NULL) all the time.

Same comment for all the _free functions.

I know I can look at the code, but that doesn't
provide an API guarantee.

Re: Accessing bignums of a RSA key with OpenSSL 3.0?

[Matt Caswell]

Note that the names are also documented here:

https://www.openssl.org/docs/manmaster/man7/EVP_KEYMGMT-RSA.html

On 30/07/2021 14:29, Olivier Mascia via openssl-users wrote:

Thanks!

BIGNUM* n;
BIGNUM* e;
BIGNUM* d;
EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_N, &n);
EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_E, &e);
EVP_PKEY_get_bn_param(cert.key(), OSSL_PKEY_PARAM_RSA_D, &d);

Now, the reverse exercise for me: to create another RSA key, solely through 
EVP_PKEY interfaces (knowing these n, e, d parameters), I think I should go 
this route:

mKey = EVP_PKEY_new();
EVP_PKEY_set_type(mKey, some int type ?);

EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_N, n2);
EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_E, e2);
EVP_PKEY_set_bn_param(mKey, OSSL_PKEY_PARAM_RSA_D, d2);

But how to get the proper int type to pass to EVP_PKEY_set_type()?


Don't do it like this. Instead you need to use EVP_PKEY_fromdata():


https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_fromdata.html


Here's an example of doing it with DSA. The same principle applies to RSA:


https://github.com/openssl/openssl/blob/5540855bda5e58f4b33f2306feb6ff4e93c0af81/apps/testdsa.h#L239-L268

Matt




Thanks all for support switching to OpenSSL 3.0.
__
Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit 
freundlichen Grüßen,
Olivier Mascia


Le 30 juil. 2021 à 15:07, Dr Paul Dale  a écrit :

Try: include/openssl/core_names.h
The names are "n", "e" and "d" in this case.


Pauli


On 30/7/21 10:57 pm, Olivier Mascia via openssl-users wrote:

Dear all,

Testing migration to OpenSSL 3.0.
Got to update some code building a JWK (in relation to ACME LetsEncrypt 
protocols).

Having an EVP_PKEY which happens to be a RSA key, I proceeded this way (1.1.1) 
to extract the bignums needed for inclusion into the JWK:

// Access the numerical components of the certificate RSA keys.
BIGNUM* n;
BIGNUM* e;
BIGNUM* d;
RSA_get0_key(cert.RSAkey(), &n, &e, &d);

( my cert.RSAkey() returned RSA* from my embedded EVP_PKEY* through 
EVP_PKEY_get0_RSA() )

I understand I should now start straight from the EVP_PKEY and use :

EVP_PKEY_get_bn_param(cert.key(), "name-n?", &n);
EVP_PKEY_get_bn_param(cert.key(), "name-e?", &e);
EVP_PKEY_get_bn_param(cert.key(), "name-d?", &d);

( cert.key() returns EVP_KEY* )

The question is: where can I find the proper names for these bignums out of a 
RSA key?

__
Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit 
freundlichen Grüßen,
Olivier Mascia

OpenSSL version VERSION published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0 beta 2 released
   ===

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

   OpenSSL 3.0 is currently in beta.

   OpenSSL 3.0 beta 2 has now been made available.  We anticipate that this
   release candidate will be the final beta release and, barring critical
   problems, that the final OpenSSL 3.0.0 release will occur in the next one
   to two weeks.

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

   Specific notes on upgrading to OpenSSL 3.0 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/manmaster/man7/migration_guide.html

   Two items of interest:

* FIPS 140-2 algorithm testing for the operational environments is currently
  in progress and OpenSSL 3.0 will be submitted to NIST for validation 
before
  the September 21st dead line.
* Engines are deprecated and will be removed in a future release. The new
  provider concept should be used instead.

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

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

   The distribution file name is:

o openssl-3.0.0-beta2.tar.gz
  Size: 14912360
  SHA1 checksum:  261ea1ad4bbf7738622bea5caa97da0283fc3166
  SHA256 checksum:  
e76ab22879201b12f014393ee4becec7f264d8f6955b1036839128002868df71

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.0-beta2.tar.gz
openssl sha256 openssl-3.0.0-beta2.tar.gz

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

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

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

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmECwXsACgkQ2cTSbQ5g
RJGIogf/d+wGwy6MQ5sYFU1skRVvJ05xXOgV9c9YwxO5UmyC3V2p6YHd6oXOhi17
lxbd5o8l9mtuIWKIMo9r222LIE8DtSrwdnO8BMpRBzxT56pUKHuF+qVmMnxOhuU6
jGkKjK6Tel8k4jLCJriRF8G0EWnWClqmvuz6z2rQkzVVcTh/TrtIJn+uMzjg1ZyZ
9T5/TljLQTtsAnx0F6i3TxgOShNpYhObWxyy4byncDX6YPdcedwHREJkhpS3pIh7
DKySPOZicP5jgHDSmp2Ip1Zl6/yTTpcQ1ncd+MHK2fPLtKmr50aCD3MF9qj49kgQ
JoXg93pEYV1gdf5aya+TgS+j5VjKeA==
=JLdr
-END PGP SIGNATURE-

Re: SSL_connect with TLS 1.3 and client Certificates

[Matt Caswell]

On 13/07/2021 19:44, Christian Schmidt wrote:

Hello all,

I am currently trying to build both client and server of an application
that uses TLS 1.3 and mutual authentication using certificates. The
application works so far - I can establish connections, certificates are
verified, data is successfully transmitted, etc.

However, I have an issue, or maybe two.

1. SSL_connect returns successfully before the client certificate is
sent from the client to the server. The client certificate is only sent
on the first SSL_write_ex with > 0 bytes, and as such, at this point the
server can generate SSL alerts like access denied, etc.


TLSv1.3 supports two types of certificate request. It can occur during 
the initial handshake, or it can occur as a post-handshake request. It 
sounds like you are doing the latter, but you want the former. Is that 
correct?


What are you doing in your code to request the certificate from the client?

Matt

Re: RSA_set0_key() equivalent for 3.0.0

[Matt Caswell]

On 13/07/2021 22:14, William Roberts wrote:
Outside of the migration guide others have pointed out, I think the 
functions you need are:


https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_set1_RSA.html 



Those functions are deprecated. Better would be EVP_PKEY_fromdata():

https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_fromdata.html

Matt



Use use EVP level now as pointed out in the guide.



On Tue, Jul 13, 2021, 16:04 Ken Goldman > wrote:


What is the 3.0.0 equivalent to RSA_set0_key() when I
want to create a key token from n and e.

Meta question:  Is there a porting guide for these
type of questions - something that says, "If you
used this before, use this now."

Re: EVP_MAC_init - specify the hash algorithm

[Matt Caswell]

On 13/07/2021 19:02, Ken Goldman wrote:

Porting to 3.0 ... HMAC_Init_ex() had a place for
the hash algorithm.  EVP_MAC_init() does not,
unless it's embedded in the 'params' parameter.

Any advice?  Or a sample for doing an
HMAC with 3.0?



If its just a straight forward HMAC you want you can do it very simply 
with the one-shot EVP_Q_mac function:


unsigned char *EVP_Q_mac(OSSL_LIB_CTX *libctx, const char *name, const 
char *propq,

 const char *subalg, const OSSL_PARAM *params,
 const void *key, size_t keylen,
 const unsigned char *data, size_t datalen,
 unsigned char *out, size_t outsize, size_t 
*outlen);


Supply "HMAC" for the name param and "SHA256" (or whatever) for the subalg.

Matt

Re: Time for OpenSSL 1.1.1l?

[Matt Caswell]

Good question! I'll raise this at OTC tomorrow.

Matt


On 07/07/2021 19:23, Short, Todd via openssl-users wrote:
The cadence of 1.1.1 release is supposed to be quarterly (I seem to 
recall reading that somewhere, but I can't find it)?


It has been almost 4 months since 1.1.1k (25-March-2021) was released.

Are there any plans for 1.1.1l (ell)?

--
-Todd Short
// tsh...@akamai.com 
// “One if by land, two if by sea, three if by the Internet."

Re: CNG engine on GitHub

[Matt Caswell]

On 02/07/2021 16:33, Matt Caswell wrote:

via the RSA_PKEY_METHOD


I meant RSA EVP_PKEY_METHOD.

Matt

Re: CNG engine on GitHub

[Matt Caswell]

On 02/07/2021 16:18, Reinier Torenbeek wrote:
It is not clear to me what you mean with "the OpenSSL engine interface 
does allow using EVP_PKEY_METHOD callbacks instead of rsa_priv_dec 
etc.". Can you elaborate (here or on the GitHub issue)?


You can hook the RSA calls at different abstraction levels. You can 
provide a custom RSA_METHOD in an enigne, which means calls to the 
various RSA_*() functions go via the custom RSA_METHOD.


However these RSA_*() functions are considered the "low level" 
functions, and it is preferred that applications use the "high level" 
EVP API instead (in fact the "low level" functions are all deprecated in 
3.0). RSA PSS padding is *only* available via the EVP API.


Algorithm specific EVP functionality is implemented via an 
EVP_PKEY_METHOD. The built-in RSA EVP_PKEY_METHOD mostly just calls the 
low level RSA_*() functions in the right places. However it implements 
PSS padding directly. Since padding has already been added via the 
RSA_PKEY_METHOD, when it actually calls the lower level RSA_*() 
functions it does so with RSA_NO_PADDING. So this means that the 
RSA_METHOD has no opportunity to influence the PSS padding.


However, an alternative is to implement a custom EVP_PKEY_METHOD. By 
doing this you get the opportunity to hook the PSS padding.


Not sure I explained that too well. I hope it makes sense.

Matt

Re: Need help in removing secp521r1 from openssl-1.1.1g and adding TLS_GREASE_BA cipher.

[Matt Caswell]

On 02/07/2021 14:02, vinod mg wrote:
--> Is there a way I can compile openssl itself to exclude 'secp521r1' 
and install? The reason I ask is because application I am testing is 
squid(squid-cache.org <http://squid-cache.org>) for ssl bumping purposes 
and it has limited configurability.


Only by disabling *all* ec groups (via the "no-ec" configure option) but 
that is no solution at all really. I would not recommend that!


You might try starting squid with the OPENSSL_CONF environment variable 
pointing to a custom OpenSSL config file. Assuming squid doesn't 
suppress loading the config file then you can do the same thing as 
SSL_CTX_set1_groups_list via the "Groups" SSL_CONF setting. See the info 
here on configuring OpenSSL SSL/TLS settings via config file (see the 
section "SSL Configuration Module"):


https://www.openssl.org/docs/man1.1.1/man5/config.html

And see the documentation on "Groups" on this page:

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

Matt



Thanks,
Vinod


On Fri, Jul 2, 2021 at 4:32 PM Matt Caswell <mailto:m...@openssl.org>> wrote:




On 01/07/2021 07:21, vinod mg wrote:
 >     1) Supress or a way to remove secp521r1 from the currenlty
installed
 >     openssl.

You can specify the list of groups by calling SSL_CTX_set1_groups_list
(or SSL_set1_groups_list) from your application. See:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html
<https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_groups_list.html>

 >     2) Add the cipher - "0xbaba   TLS_GREASE_BA   GREASE" like we
see in
 >     chrome.

This is not a real cipher. It does nothing and is always ignored.
OpenSSL does not support sending this value.

Matt


 >
 >     I am ok with custom install as well, if above cannot be done with
 >     already installed openssl package. Please share any wiki I can
 >     follow to impliment the same.
 >
 >     ~]# openssl ecparam -list_curves
 >
 >     secp224r1 : NIST/SECG curve over a 224 bit prime field
 >
 >     secp256k1 : SECG curve over a 256 bit prime field
 >
 >     secp384r1 : NIST/SECG curve over a 384 bit prime field
 >
 >     /secp521r1 : NIST/SECG curve over a 521 bit prime field/
 >
 >     prime256v1: X9.62/SECG curve over a 256 bit prime field
 >
 >
 >     I am using below OS and version-
 >
 >     # cat /etc/redhat-release
 >
 >     Red Hat Enterprise Linux release 8.3 (Ootpa)
 >
 >
 >     # opensslversion -a
 >
 >     OpenSSL 1.1.1g FIPS21 Apr 2020
 >
 >     built on: Thu Mar 25 16:46:53 2021 UTC
 >
 >     platform: linux-x86_64
 >
 >     options:bn(64,64) md2(char) rc4(16x,int) des(int) idea(int)
 >     blowfish(ptr)
 >
 >     compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3
-O2 -g
 >     -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 >     -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
 >     -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 >     -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 >     -fasynchronous-unwind-tables -fstack-clash-protection
 >     -fcf-protection -Wa,--noexecstack
 >     -Wa,--generate-missing-build-notes=yes
 >     -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-DOPENSSL_USE_NODELETE
 >     -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
 >     -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m
 >     -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
 >     -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
 >     -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY
 >     -DDEVRANDOM="\"/dev/urandom\""
 >   
  -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"

 >
 >     OPENSSLDIR: "/etc/pki/tls"
 >
 >     ENGINESDIR: "/usr/lib64/engines-1.1"
 >
 >     Seeding source: os-specific
 >
 >     engines:rdrand dynamic
 >
 >
 >     Really appriciate your time and help, thanks in advance.
 >
 >     Thanks,
 >     Vinod
 >

Re: Need help in removing secp521r1 from openssl-1.1.1g and adding TLS_GREASE_BA cipher.

[Matt Caswell]

On 01/07/2021 07:21, vinod mg wrote:

1) Supress or a way to remove secp521r1 from the currenlty installed
openssl.


You can specify the list of groups by calling SSL_CTX_set1_groups_list 
(or SSL_set1_groups_list) from your application. See:


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


2) Add the cipher - "0xbaba   TLS_GREASE_BA   GREASE" like we see in
chrome.


This is not a real cipher. It does nothing and is always ignored. 
OpenSSL does not support sending this value.


Matt




I am ok with custom install as well, if above cannot be done with
already installed openssl package. Please share any wiki I can
follow to impliment the same.

~]# openssl ecparam -list_curves

secp224r1 : NIST/SECG curve over a 224 bit prime field

secp256k1 : SECG curve over a 256 bit prime field

secp384r1 : NIST/SECG curve over a 384 bit prime field

/secp521r1 : NIST/SECG curve over a 521 bit prime field/

prime256v1: X9.62/SECG curve over a 256 bit prime field


I am using below OS and version-

# cat /etc/redhat-release

Red Hat Enterprise Linux release 8.3 (Ootpa)


# opensslversion -a

OpenSSL 1.1.1g FIPS21 Apr 2020

built on: Thu Mar 25 16:46:53 2021 UTC

platform: linux-x86_64

options:bn(64,64) md2(char) rc4(16x,int) des(int) idea(int)
blowfish(ptr)

compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -Wa,--noexecstack
-Wa,--generate-missing-build-notes=yes
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE
-DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
-DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
-DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY
-DDEVRANDOM="\"/dev/urandom\""
-DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"

OPENSSLDIR: "/etc/pki/tls"

ENGINESDIR: "/usr/lib64/engines-1.1"

Seeding source: os-specific

engines:rdrand dynamic


Really appriciate your time and help, thanks in advance.

Thanks,
Vinod

Re: How to simulate "TLS 1.3 Session Resumption" through OpenSSL tools?

[Matt Caswell]

On 02/07/2021 10:09, Nan Xiao wrote:

Hi OpenSSL users,

Greetings from me! From this article
(https://www.qacafe.com/resources/examples-of-tls-1-3/) and pcap file
(https://www.cloudshark.org/captures/64d433b1585a), I know we can use
s_server and s_client to simulate "TLS 1.3 Session Resumption". I
tried following command:

echo | openssl s_client -tls1_3  -connect tls13.cloudflare.com:443 -reconnect



That looks like you've stumbled across an s_client bug. This should 
work, but it doesn't appear to. I just raised an issue for it:


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




But it seems not to work since there is no "pre_shared_key" extension,
and every time s_client just initiated a new connection instead of
resumption.

Could anybody advise how to simulate "TLS 1.3 Session Resumption"
through OpenSSL tools? Thanks very much in advance!


You can do this another way. Create an initial connection (add 
"-connect" option as appropriate):


openssl s_client -tls1_3 -sess_out sess.pem

And then resume like this:

openssl s_client -tls1_3 -sess_in sess.pem

However, note that with TLSv1.3 the session data doesn't arrive until 
post-handshake. In the case of the cloudflare server it doesn't send any 
session tickets until it has received some application data from the 
client. So in order to get a valid resumable session you will have to 
type some HTTP command into s_client once it has created its initial 
connection. This should cause the cloudflare server to respond with a 
session ticket, which will get saved to the sess.pem file. You can then 
use that in the subsequent resumption attempt.


Matt

Re: CNG engine on GitHub

[Matt Caswell]

On 02/07/2021 04:25, Reinier Torenbeek wrote:

Hi Matt,

I am aware of the deprecation of the engine interface with 3.0 but have not 
looked into the details of support providers yet. I  expect converting an 
engine to a support provider could be done with quite a bit of code reuse, 
correct? Would you say the interface and design of support providers is stable 
at this point?


The engine and provider interfaces are quite different - but since the 
underlying operations are the same I imagine there will be quite a bit 
of reuse.


Yes, we consider the provider interface to be stable now.

Matt




Thanks,
Reinier


On Jul 1, 2021, at 4:41 PM, Matt Caswell  wrote:

Nice! Are there any thoughts to support providers? The engine interface is 
deprecated in 3.0.

Matt



On 01/07/2021 18:49, Reinier Torenbeek wrote:
Hi,
For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you may want to check 
out this new OpenSSL CNG Engine project on GitHub: 
https://github.com/rticommunity/openssl-cng-engine 
<https://github.com/rticommunity/openssl-cng-engine> . The associated User's Manual 
is on ReadTheDocs: https://openssl-cng-engine.readthedocs.io/en/latest/index.html 
<https://openssl-cng-engine.readthedocs.io/en/latest/index.html> .
The project implements the majority of the EVP interface, to leverage the 
BCrypt crypto implementations, as well as a subset of the STORE interface, for 
integration with the Windows Certificate and Keystore(s), via the NCrypt and 
Cert APIs. It has been tested with 1.1.1k on Windows 10, with Visual Studio 
2017 and 2019. It is released under the Apache-2.0 license.
Any feedback is welcome, please send it to me or open an issue on GitHub.
Best regards,
Reinier

Re: CNG engine on GitHub

[Matt Caswell]

Nice! Are there any thoughts to support providers? The engine interface 
is deprecated in 3.0.


Matt


On 01/07/2021 18:49, Reinier Torenbeek wrote:

Hi,

For anyone interested in leveraging Windows CNG with OpenSSL 1.1.1, you 
may want to check out this new OpenSSL CNG Engine project on GitHub: 
https://github.com/rticommunity/openssl-cng-engine 
 . The associated 
User's Manual is on ReadTheDocs: 
https://openssl-cng-engine.readthedocs.io/en/latest/index.html 
 .


The project implements the majority of the EVP interface, to leverage 
the BCrypt crypto implementations, as well as a subset of the STORE 
interface, for integration with the Windows Certificate and Keystore(s), 
via the NCrypt and Cert APIs. It has been tested with 1.1.1k on Windows 
10, with Visual Studio 2017 and 2019. It is released under the 
Apache-2.0 license.


Any feedback is welcome, please send it to me or open an issue on GitHub.

Best regards,
Reinier

Re: [EXTERNAL] Re: GNU Make erroring on makefile

[Matt Caswell]

On 01/07/2021 15:06, Joe Carroll wrote:

Windows 10
perl Configure VC-WIN64A


The VC-WIN64A target generates a Makefile suitable for consumption by 
nmake. Hence its not possible to use GNU make with it.


It *is* possible to build for Windows using GNU make with a different 
target however.


To do this you must first install MSYS2 with the mingw compiler packages 
and associated toolchain, as well as the MSYS2 version of perl (*not* 
other versions of perl).


Then you can configure and build as normal:

perl Configure mingw64
make
make test
make install

See the section "mingw and mingw64" in NOTES.WIN.

Matt







-Original Message-
From: Richard Levitte [mailto:levi...@openssl.org]
Sent: Thursday, July 1, 2021 8:25 AM
To: Joe Carroll 
Cc: openssl-users@openssl.org
Subject: [EXTERNAL] Re: GNU Make erroring on makefile

How did you configure, and on what platform?

On Thu, 01 Jul 2021 15:22:46 +0200,
Joe Carroll wrote:


Has anyone successfully used GNU Make as part of the install process for 
version 1.1.1k or later?
I'm getting a "missing separator" error on line 56.  I do not have access to 
nmake.exe.
  
!IF "$(DESTDIR)" != ""

Re: SM2/3/4 algorithm based TLS connections

[Matt Caswell]

On 29/06/2021 10:29, Kevin Lengauer wrote:

Dear openssl-team and users

Is it possible with OpenSSL 1.1.1k to do a TLS handshake using key 
material and certificate based on SM2/SM3/SM4 assuming I somehow got my 
hands on such keys/certificates?


I think it is only possible with OpenSSL 3.0 to create them.

After checking the web and the source code of the recent OpenSSL 1.1.1k 
version I doubt that this is possible and also did not find any 
corresponding cipher suites.


Is this assumption correct or is there a way to do a TLS1.2 or TLS1.3 
handshake with the aforementioned algorithms?


You are correct, there are no suitable ciphersuites and it is not 
possible to add an SM2 based certificate to an SSL_CTX/SSL.





I am aware that the Chinese “GM/T 0024” protocol is not part of OpenSSL 
(yet) based on this github issue: 
https://github.com/openssl/openssl/issues/12473 



Correct.

Matt

Re: openssl 3.0 beta versus actual

[Matt Caswell]

On 25/06/2021 08:01, Sandeep Umesh wrote:

Hello
While the beta version has been released now, please let us know if 
there is any timeline to release the actual 3.0 version ?
What changes are expected to be 3.0 version compared to its beta ? it is 
restricted to bug-fixes only ?


We are expecting 3.0 actual to be released in Q3 of this year.

Beta is bug fixes only - no new features.

Matt

Re: Blog post

[Matt Caswell]

On 17/06/2021 18:35, Ethan Rahn wrote:

Hello Matt,

Love the blog post, and of course a hearty thanks to everyone who worked 
on the project to get it to this point.


Is the plan still to continue with the FIPS 140-2 validation instead of 
140-3? Apologies for the lack of a first party source but 
https://www.leidos.com/insights/fips-140-and-common-criteria-industry-updates-march-2020 
<https://www.leidos.com/insights/fips-140-and-common-criteria-industry-updates-march-2020> 
lists Sept 22, 2021 as the last day for FIPS 140-2 submissions. Is 
OpenSSL 3.0 going to be submitted by then?


Yes we plan to submit a 140-2 validation by the September deadline.

Matt




Cheers,

Ethan

On Thu, Jun 17, 2021, 06:43 Matt Caswell <mailto:m...@openssl.org>> wrote:


For anyone interested I've written a blog post to accompany the 3.0
beta
1 release. You can read it here:

https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/
<https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/>

Matt

Re: OpenSSL version 3.0.0-beta1 published

[Matt Caswell]

On 17/06/2021 15:43, Steffen Nurpmeso wrote:

Fyi, i have $PERL5OPT=-C permanently in my environment, in
conjunction with LC_ALL=en_US.utf8 this results in the build error
as below.  Prefixing LC_ALL=C fixes this.


Thanks. I submitted this as an issue on github here:

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

Matt



   #?0|kent:src$ MYPREFIX=$HOME/$USR/opt/.ossl3 make -j4 openssl
   cd tls-openssl.git &&\
   if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
   ./config --prefix=/home/steffen/usr-kent-linux-x86_64/opt/.ossl3 
zlib-dynamic shared \
   no-deprecated no-async threads no-tests \
   -Wl,-rpath,'' &&\
   make &&\
make install_sw &&  make install_ssldirs; \
   { git clean -fxd; git reset --hard HEAD;\
   git checkout arena-manager-null; } >/dev/null
   Switched to branch 'master'
   Your branch is up to date with 'origin/master'.
   Configuring OpenSSL version 3.0.0-beta2-dev for target linux-x86_64
   Using os-specific seed configuration
   Creating configdata.pm
   Running configdata.pm
   Creating Makefile.in
   syswrite() isn't allowed on :utf8 handles at 
/usr/lib/perl5/5.32/File/Copy.pm line 181.
   Switched to branch 'arena-manager-null'

Blog post

[Matt Caswell]

For anyone interested I've written a blog post to accompany the 3.0 beta 
1 release. You can read it here:


https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/

Matt

OpenSSL version 3.0.0-beta1 published

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0 beta 1 released
   ===

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

   OpenSSL 3.0 is currently in beta.

   OpenSSL 3.0 beta 1 has now been made available.

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

   Specific notes on upgrading to OpenSSL 3.0 from previous versions are
   available in the OpenSSL Migration Guide, here:

https://www.openssl.org/docs/manmaster/man7/migration_guide.html

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

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

   The distribution file name is:

o openssl-3.0.0-beta1.tar.gz
  Size: 14878832
  SHA1 checksum:  4b48947969bb3c989ba95ac4bdc4a78e70212d2b
  SHA256 checksum:  
7bfedc9a1062cbd2aabc294acc93cbd5259e6e7bd5bbe38e454cc6a32564029f

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.0-beta1.tar.gz
openssl sha256 openssl-3.0.0-beta1.tar.gz

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

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

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

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmDLSDUACgkQ2cTSbQ5g
RJHPJQf9GACe9xem5BnK1EPAJtWkXxKZS3NOThT5rp6mCArFCVX3Vvrmui/PUgL2
+EPA9o96G6SJ/AypFyH/SUYfK2weC7LmPGgZ4kk0Od/rn/JE+Pkbk1IyqTb3QnUz
LlMIB69m8vx/IJqP/FSCY224iP+gtCzyQvktxra1dLab7SJtDiTtcvvSKv20jd1+
9V9GSPIrl1G7dU+aWG/jZRZ1g8lmVEoZ/d3wKpddU3A31mSWxyt8Yc5/gRC74NmU
EGCHY+6hrrRIoJkIiywlk9HoFQNHf3OT0pK1F8Igfredos6dulUKxcK2jk0gJjQY
IG7aAF+ZcysQZ5y0iUksHhb296mRNA==
=Jk01
-END PGP SIGNATURE-

Re: What's the rationale behind ssl-trace not being built by default?

[Matt Caswell]

On 08/06/2021 00:09, Arran Cudbard-Bell wrote:




On Jun 7, 2021, at 4:57 PM, Matt Caswell  wrote:



On 07/06/2021 20:01, Arran Cudbard-Bell wrote:

The tables to convert extension IDs and compression methods to humanly readable 
names are not available outside ssl/t1_trace.c.
SSL_trace() itself produces reams of helpful information as handshakes 
progress, and is particularly useful for dealing with encrypted handshakes, 
where wireshark et al don't provide useful output.
What is the rationale for ssl-trace to be disabled by default?  Was it purely 
to keep binary sizes down, or was there a security aspect to the decision?


Its a really good question and I've often wondered the same thing. The decision 
was made before my time. I suspect it was about keeping binary sizes down, but 
I can't imagine it would make that much difference. I have previously 
considered turning it on by default but never quite got around to it.


If you don't have any objections I could submit a PR to enable it by default?  
I'd image that the platforms that'd care about a few extra kb are in the 
minority, and it makes such a huge difference having SSL_trace() when trying to 
debug TLS 1.3 issues.


I have no objections although you'll have to be quick if you want it 
considered for 3.0. Since it would just be about changing the default 
people that care about the extra kb can still disable it.


Matt

Re: What's the rationale behind ssl-trace not being built by default?

[Matt Caswell]

On 07/06/2021 20:01, Arran Cudbard-Bell wrote:

The tables to convert extension IDs and compression methods to humanly readable 
names are not available outside ssl/t1_trace.c.

SSL_trace() itself produces reams of helpful information as handshakes 
progress, and is particularly useful for dealing with encrypted handshakes, 
where wireshark et al don't provide useful output.

What is the rationale for ssl-trace to be disabled by default?  Was it purely 
to keep binary sizes down, or was there a security aspect to the decision?


Its a really good question and I've often wondered the same thing. The 
decision was made before my time. I suspect it was about keeping binary 
sizes down, but I can't imagine it would make that much difference. I 
have previously considered turning it on by default but never quite got 
around to it.


Matt

Re: Replay HTTP traffic

[Matt Caswell]

On 17/05/2021 14:41, Григорий Сморкалов wrote:

Hello. I am trying to debug some ssl related code and I need some help.

We have a HTTP client based on libuv and libopenssl for TLS. It is an 
internal C++ library with its own TCP wrapper around lubuv and HTTP 
parser. It works fine and our servers make millions of HTTPS requests to 
social networks with it. If it is one connection per request 
(Connection: Close) there is no problem at all. But sometimes 
connections with keep-alive receive strange ssl errors:


error:04067084:rsa routines:rsa_ossl_public_decrypt:data too large for 
modulus , or error:04067072:rsa routines:rsa_ossl_public_decrypt:padding 
check failed


It is a really rare event, once per million I think. The error is 
returned from SSL_read when new data comes from the server. It is never 
the first response, usually there are more than ten requests/responses 
in the connection before the error.


If I understand you correctly then you are seeing this at some point 
*after* the initial handshake and the connection has been running for a 
while.


If so that is a very strange error indeed. These are RSA errors. But 
once the initial handshake is complete there should be no reason for 
libssl to be performing RSA calls. RSA is *only* used during the 
handshake and not during application data transfer. Unless that is there 
is a reneg handshake happening (only applies for TLSv1.2 or less)...but 
if so that would be fairly clear in the wireshark logs.


Does your application do anything with libcrypto directly? Or does it 
only use libssl?


Is your client application multi-threaded?

I'm wondering whether this error is actually a stale error left in the 
queue from some earlier problem on the same thread.


You could try forcefully clearing any stale errors (ERR_clear_error()) 
before any SSL_read() calls and see if the problem goes away.





We have a tcpdump of such connections and keylog made with 
SSL_CTX_set_keylog_callback. Wireshark opens this dump and decrypts it 
normally using keylog as pre-master keyfile. The last packet produces an 
error in our HTTP client but in wireshark it is ok and it contains 
normal HTTP response with 200 OK. No sign of any error or data 
corruption. That fact makes me think that data is ok and my openssl 
usage has some problems.


I want to reproduce this situation and replay this tcpdump. It means run 
our server (actually only http client part) and give it captured data. 
It is no problem to make a server that sends exactly the same data from 
tcp dump. It is no problem to make exactly the same http request. But I 
need to use the pre-master key from the keylog on the client side. I 
cannot find any function that sets keys to SSL_CTX* or SSL*. Is there any?


I tried to build my own libopenssl with constant keys. I put 
memcpy(s->session->master_key, overriden_secret, 48) in 
ssl_generate_master_secret and tls13_generate_secret. Also 
memcpy(s->s3->client_random, overriden_random, 32); in 
tls_construct_client_hello and tls_early_post_process_client_hello. It 
doesn't work and produces ssl error on handshake phase 
error:1416C095:SSL routines:tls_process_finished:digest check failed. 
Client Hello produced by this patched libopenssl is always different, 
this means I haven't replaced all keys. It is something in s->tmp 
structure I cannot understand to replace all usages and values.


This is very much a non-trivial task. OpenSSL has no support for this 
kind of thing at the moment and it would be difficult to add it. I don't 
think the key logging logs the ephemeral keys that are used as input to 
the master secret generation. So the ClientHello key_share (assuming 
TLSv1.3) is going to be different regardless.


You could conceivably hack the finished check so that it passes 
regardless if you still end up with the right master secret - but 
everything isn't necessarily going to be the *same* as in the initial 
failing run. If my possibly theory about a stale error on the queue is 
right then even if you got everything right then it might still not show 
up the problem if the stale error is related to some other thing that 
happened on the same thread.


Matt





Is there a simpler way?

Without reproducing it is practically impossible to find a bug. Even if 
it does not reproduce, I'll get some information. Maybe it is UB in a 
different place.


I've asked the same question on stackoverflow, so you can answer there 
if it is easier or better for you: 
https://stackoverflow.com/questions/67570255/how-to-replay-encrypted-traffic-with-libopenssl 



Thank you!

Re: SHA digest differences in version 1.0 and 1.1.1

[Matt Caswell]

On 14/05/2021 09:21, openssl@benshort.co.uk wrote:

Hi,

I am working with some legacy code which was written to use openssl 
version 1.0.


I am trying to make it work with openssl version 1.1.1 but the following 
line returns NULL.


     const EVP_MD* messageDigest = EVP_get_digestbyname("sha");

I changed it to the following.

     const EVP_MD* messageDigest = EVP_get_digestbyname("sha1");

That does return a EVP_MD pointer but when I use it with a EVP_MD_CTX to 
create a hash it produces a different hash than the legacy code for the 
same data.


What digest was returned by "sha" in the older version?



That is "SHA-0". A very early (1993) implementation of what later became 
SHA-1. According to Wikipedia SHA-0: "...was withdrawn by the NSA 
shortly after publication and was superseded by the revised version, 
published in 1995 in FIPS PUB 180-1 and commonly designated SHA-1.


SHA-0 really really should not be used and support was removed in 
OpenSSL 1.1.0.


Matt

Re: Install/Build openssl with following ciphers - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_G

[Matt Caswell]

On 11/05/2021 05:24, Mario Ds Briggs wrote:

thanks Matt. I couldnt find the -stdname option on my macOS openssl,


In that case you are most likely not using OpenSSL at all but LibreSSL. 
Or possibly a very old version of OpenSSL.


but 
using ur example above, i could find the ones they map to. So I am good 
and thanks very much for your kind help.
Bonus question :-) I have a 2 more 
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 
and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
I dont even find these listed on the man pages - 
https://www.openssl.org/docs/man1.0.2/man1/ciphers.html 
 and hence was 
curious


Support for ChaCha20/Poly1305 was first added in OpenSSL 1.1.0 so they 
are not listed in the 1.0.2 man pages you are referring to.


You will find these ciphers in the man pages for the current 1.1.1 
version here:


https://www.openssl.org/docs/man1.1.1/man1/ciphers.html


Matt

Re: Install/Build openssl with following ciphers - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_G

[Matt Caswell]

On 10/05/2021 06:38, Mario Ds Briggs wrote:
In the openssl libs that i have installed on ubuntu/rhel/mac-os, i dont 
find the following ciphers when i run 'openssl ciphers' command
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256


These are the standard IETF names for these ciphersuites. OpenSSL calls 
them something slightly different. So for example 
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" is known as 
"ECDHE-ECDSA-AES256-GCM-SHA384" in OpenSSL.


Most likely you are using a version of OpenSSL that does have support 
for these ciphersuites, but you are not seeing it in the "ciphers" 
output because of the above. You can get "ciphers" to display the 
standard name as well as the OpenSSL name using the command below:


$ openssl ciphers -v -stdname


Matt

Re: Creating a CSR using OpenSSL v1.1.1

[Matt Caswell]

On 29/04/2021 15:04, Joe Eremita wrote:

datasig_len = i2d_X509_REQ_INFO( req->req_info, NULL );


You can achieve this by instead doing:

datasig_len = i2d_re_X509_REQ_tbs(req, NULL);

See:

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

Matt

Re: How to access different fields of typedef struct evp_pkey_st EVP_PKEY.

[Matt Caswell]

On 20/04/2021 11:45, Kumar Mishra, Sanjeev wrote:

Hi,
I am not getting different functions in OpenSSL 3.0 for accessing 
different fields of typedef struct evp_pkey_st EVP_PKEY. For Example - 
code is like this -

EVP_PKEY * privKey;
-
-
if ( BN_cmp(privKey->pkey.rsa->n, pubKey->pkey.rsa->n) != 0 )


BIGNUM *privn = NULL, *pubn = NULL;

/* Error handling omitted for brevity...*/
EVP_PKEY_get_bn_param(privKey, "n", &privn);
EVP_PKEY_get_bn_param(pubKey, "n", &pubKey);
if ( BN_cmp(privn, pubn) != 0)

...
BN_free(privn);
BN_free(pubn);




else if ((privKey->type == EVP_PKEY_EC) && (pubKey->type == EVP_PKEY_EC))



else if (EVP_PKEY_is_a(privKey, "EC") && (EVP_PKEY_is_a(pubKey, "EC"))



Matt

Re: PKCS#1 RSAPublicKey in Openssl 3.0

[Matt Caswell]

On 20/04/2021 06:30, Paramashivaiah, Sunil wrote:

Hi All,

      PEM_read_bio_RSAPublicKey is deprecated in Openssl 3.0. I am 
unable to find

      an alternate API to get EVP_PKEY from Pem format PKCS#1 Public key.
      Is PKCS#1 Public key not supported in Openssl 3.0
      Please suggest me how to get EVP_PKEY from Pem format PKCS#1 
Public key in Openssl 3.0




The functions PEM_read_bio_PUBKEY() or PEM_read_bio_PUBKEY_ex() can read 
an RSA PKCS#1 public key in PEM format and returns it as an EVP_PKEY 
(RSA_read_bio_PUBKEY is also available in older versions of OpenSSL).


Alternatively you can use the newer and more flexible 
OSSL_DECODER_CTX_new_for_pkey() and OSSL_DECODER_from_bio().


Matt

Re: Maiising Daily Snapshots for 20210416

[Matt Caswell]

There was a power outage at the datacentre last night. Everything should 
hopefully be back to normal now, so hopefully the snapshots will arrive 
as normal tonight.


Matt


On 16/04/2021 14:25, The Doctor wrote:

Anyone knows what happened?

Re: Fwd: Question about RSA key access mechanism

[Matt Caswell]

On 12/04/2021 09:57, Danis Ozdemir wrote:
When I define a watchpoint for that address to verify that it has been 
accessed when a new client connects to the server and make the server 
continue, I can't see a hit which means this address hasn't been 
accessed. *I'm attaching the s_client output as a file, since it's 
longer compared to the outputs above.*


You don't say which version of OpenSSL you are using (1.1.1 or 3.0?). 
That can make a big difference to the codepaths that you go through to 
get to actual RSA operations.


I'm assuming you are interested in the RSA signature from a TLSv1.3 
CertVerify message.


If so I would expect you to end up in the rsa_ossl_mod_exp function in 
crypto/rsa/rsa_ossl.c. It's there that I would expect to see accesses to 
"p". I suggest you set a breakpoint in that function and see what is 
happening.


Matt




*
*
I then dumped the whole non-executable pages that were allocated for 
this process using ptrace to see whether another copy of the key was 
present and I couldn't find any copies. So, either I'm doing something 
wrong (which is the case, most probably) or there's another area which 
contains another representation of the key for security reasons (given 
the fact that the raw key content is accessible in the RAM, this one 
seems less likely). Therefore, assuming I'm doing something wrong, if 
you could tell me what it is, I'd be grateful.


Best regards,
Danis Ozdemir

**

Re: Strange warnings while linking to openssl version 1.1.1k

[Matt Caswell]

On 12/04/2021 21:52, Robert Smith via openssl-users wrote:

Hi,

I am getting the following warning while linking my app to openssl 
version 1.1.1k. Could you advise what can cause these warnings and how 
to resolve them? Thanks


It looks like your environment cannot support the async functionality. 
Compile OpenSSL with the "no-async" compile time option to squash these 
warnings.


Matt





../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `ASYNC_is_capable':
async_posix.c:(.text+0x48): warning: warning: getcontext is not 
implemented and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async.o): In function 
`async_fibre_swapcontext':
async.c:(.text+0x248): warning: warning: setcontext is not implemented 
and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `async_fibre_makecontext':
async_posix.c:(.text+0xe8): warning: warning: makecontext is not 
implemented and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `ASYNC_is_capable':
async_posix.c:(.text+0x48): warning: warning: getcontext is not 
implemented and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async.o): In function 
`async_fibre_swapcontext':
async.c:(.text+0x248): warning: warning: setcontext is not implemented 
and will always fail
../../../artifacts/openssl/arm3531/lib/libcrypto.a(async_posix.o): In 
function `async_fibre_makecontext':
async_posix.c:(.text+0xe8): warning: warning: makecontext is not 
implemented and will always fail

Re: error: redefinition of ‘struct rsa_meth_st’

[Matt Caswell]

On 12/04/2021 18:06, Blumenthal, Uri - 0553 - MITLL wrote:

Is there an analog of the "dummy async engine" for the OpenSSL-3.0 Provider?


There isn't a simple analog for RSA specifically.

There's the test "tls-provider" which implements a toy KEX and KEM 
algorithm:


https://github.com/openssl/openssl/blob/master/test/tls-provider.c

For a bare bones skeleton do-nothing provider you can look at the null 
provider:


https://github.com/openssl/openssl/blob/master/providers/nullprov.c

You can also have a look at the legacy provider for a (relatively) 
simple example of how to do ciphers and digests:


https://github.com/openssl/openssl/blob/master/providers/legacyprov.c

Of course you should also look at the documentation:

https://www.openssl.org/docs/manmaster/man7/provider.html

If the interest is RSA specifically you may want to look at the provider 
asymmetric cipher documentation:


https://www.openssl.org/docs/manmaster/man7/provider-asym_cipher.html

as well as the provider signatures documentation:

https://www.openssl.org/docs/manmaster/man7/provider-signature.html

and the provider key management documentation:

https://www.openssl.org/docs/manmaster/man7/provider-keymgmt.html


Matt



TNX
--
Regards,
Uri
  
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

  -  C. A. R. Hoare
  


On 4/12/21, 12:43, "openssl-users on behalf of Matt Caswell" 
 wrote:

 You can look at the dummy async engine which wraps the standard RSA
 functions inside an engine (as well as various other crypto primitives).
 You can see it here:

 
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/engines/e_dasync.c

 Matt

 On 12/04/2021 17:32, Shariful Alam wrote:
 > Dr. Pauli,
 > Goodmorning. Thank you for replying. I found the documentation a bit
 > difficult for me to understand. I was wondering if you can direct me to
 > a sample skeleton code for creating a custom RSA engine.
 >
 > Regards,
 > Shariful Alam
 >
 > On Sun, Apr 11, 2021 at 6:00 PM Dr Paul Dale  <mailto:pa...@openssl.org>> wrote:
 >
 > You shouldn't be accessing the internal of a private structure. That
 > structure was made private for a reason and duplicating it in your
 > engine will break when we change the structure's contents.
 >
 > Your engine should be using the EVP_PKEY_meth_set_* function to do
 > what you want (for 1.1.1).  For 3.0, you should be writing a
 > provider instead.
 >
 >
 > Pauli
 >
 > On 12/4/21 5:04 am, Shariful Alam wrote:
 >> Hello,
 >> Hope you guys are doing well. I'm trying to develop an RSA engine.
 >> My engine was somewhat working until I try to integrate my engine
 >> with an apache httpd server. After installing the httpd from the
 >> source code, it turns out that, I can't compile my engine anymore.
 >> I get the following error while I try to compile (it was compiling
 >> before and I did not make any changes to my engine code).
 >>
 >> ==
 >>
 >> *$gcc -fPIC -c r_engine.c*
 >> *r_engine.c:29:8: error: redefinition of ‘struct rsa_meth_st’
 >>  struct rsa_meth_st {
 >> ^
 >> In file included from /usr/include/openssl/crypto.h:131:0,
 >>  from r_engine.c:7:
 >> /usr/include/openssl/ossl_typ.h:147:16: note: originally defined 
here
 >>  typedef struct rsa_meth_st RSA_METHOD;*
 >>
 >> =
 >>
 >> and my *struct rsa_meth_st *looks like the following,
 >>
 >> 

 >>
 >> *struct rsa_meth_st {
 >>
 >> const char *name;
 >> int (*rsa_pub_enc) (int flen, const unsigned char *from,
 >> unsigned char *to, RSA *rsa, int padding);
 >> int (*rsa_pub_dec) (int flen, const unsigned char *from,
 >> unsigned char *to, RSA *rsa, int padding);
 >> int (*rsa_priv_enc) (int flen, const unsigned char *from,
 >> unsigned char *to, RSA *rsa, int padding);
 >> int (*rsa_priv_dec) (int flen, const unsigned char *from,
 >> unsigned char *to, RSA *rsa, int padding);

Re: error: redefinition of ‘struct rsa_meth_st’

[Matt Caswell]

You can look at the dummy async engine which wraps the standard RSA 
functions inside an engine (as well as various other crypto primitives). 
You can see it here:


https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/engines/e_dasync.c

Matt

On 12/04/2021 17:32, Shariful Alam wrote:

Dr. Pauli,
Goodmorning. Thank you for replying. I found the documentation a bit 
difficult for me to understand. I was wondering if you can direct me to 
a sample skeleton code for creating a custom RSA engine.


Regards,
Shariful Alam

On Sun, Apr 11, 2021 at 6:00 PM Dr Paul Dale > wrote:


You shouldn't be accessing the internal of a private structure. That
structure was made private for a reason and duplicating it in your
engine will break when we change the structure's contents.

Your engine should be using the EVP_PKEY_meth_set_* function to do
what you want (for 1.1.1).  For 3.0, you should be writing a
provider instead.


Pauli

On 12/4/21 5:04 am, Shariful Alam wrote:

Hello,
Hope you guys are doing well. I'm trying to develop an RSA engine.
My engine was somewhat working until I try to integrate my engine
with an apache httpd server. After installing the httpd from the
source code, it turns out that, I can't compile my engine anymore.
I get the following error while I try to compile (it was compiling
before and I did not make any changes to my engine code).

==

*$gcc -fPIC -c r_engine.c*
*r_engine.c:29:8: error: redefinition of ‘struct rsa_meth_st’
 struct rsa_meth_st {
        ^
In file included from /usr/include/openssl/crypto.h:131:0,
                 from r_engine.c:7:
/usr/include/openssl/ossl_typ.h:147:16: note: originally defined here
 typedef struct rsa_meth_st RSA_METHOD;*

=

and my *struct rsa_meth_st *looks like the following,




*struct rsa_meth_st {

    const char *name;
    int (*rsa_pub_enc) (int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding);
    int (*rsa_pub_dec) (int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding);
    int (*rsa_priv_enc) (int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding);
    int (*rsa_priv_dec) (int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding);

    int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa,
BN_CTX *ctx);

    int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM
*p, const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);

    int (*init) (RSA *rsa);

    int (*finish) (RSA *rsa);

    int flags;

    char *app_data;

    int (*rsa_sign) (int type, const unsigned char *m, unsigned
int m_length, unsigned char *sigret, unsigned int *siglen, const
RSA *rsa);

    int (*rsa_verify) (int dtype, const unsigned char *m, unsigned
int m_length, const unsigned char *sigbuf, unsigned int siglen,
const RSA *rsa);

    int (*rsa_keygen) (RSA *rsa, int bits, BIGNUM *e, BN_GENCB *cb);

};
*


=

My sample skeleton code is here https://pastebin.com/uNXYknEA


Can anyone please tell me what I'm I doing wrong?

Regards,
Shariful Alam

Re: Compilation issue with 1.1.1k version

[Matt Caswell]

On 07/04/2021 20:02, Boris Shpoungin wrote:

In my sources there is no definition for that macro, this is the problem:

user@ubuntu_dev_vm:~/tools/openssl/1.1.1k$ grep -HRn 'set_sys_error' .
./crypto/err/err.c:259:    set_sys_error(saveerrno);
./crypto/err/err.c:750:    set_sys_error(saveerrno);
./crypto/err/err.c:784:    set_sys_error(saveerrno);
./crypto/dso/dso_dlfcn.c:126:    set_sys_error(saveerrno);


Seems you have corrupt sources. For me:

$ grep -HRn 'set_sys_error'
crypto/err/err.c:259:set_sys_error(saveerrno);
crypto/err/err.c:750:set_sys_error(saveerrno);
crypto/err/err.c:784:set_sys_error(saveerrno);
crypto/dso/dso_dlfcn.c:126:set_sys_error(saveerrno);
e_os.h:77:# define set_sys_error(e)errno=(e)
e_os.h:95:#  undef set_sys_error
e_os.h:98:#  define set_sys_error(e)SetLastError(e)

Matt



Any idea why?
Thanks

On Wednesday, April 7, 2021, 02:39:46 PM EDT, Matt Caswell 
 wrote:





On 07/04/2021 19:31, Boris Shpoungin via openssl-users wrote:
 > Hello,
 >
 > I am using cross compiler toolchain (arm-hisiv200-linux-gnueabi) to
 > compile openssl library for arm based custom board.
 > I had no problems to compile version 1.1.1a, however I am having
 > troubles to compile versions 1.1.1i and 1.1.1k:
 >
 > ${LDCMD:-arm-hisiv200-linux-gnueabi-gcc} -pthread -Wa,--noexecstack
 > -Wall -O3 -L.   \
 > -o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o
 > apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o
 > apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o
 > apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o
 > apps/ocsp.o apps/openssl.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o
 > apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o
 > apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o
 > apps/s_client.o apps/s_server.o apps/s_time.o apps/sess_id.o
 > apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/storeutl.o
 > apps/ts.o apps/verify.o apps/version.o apps/x509.o \
 > apps/libapps.a -lssl -lcrypto -ldl -pthread
 > ./libcrypto.so: undefined reference to `set_sys_error'
 > collect2: ld returned 1 exit status
 > Makefile:6271: recipe for target 'apps/openssl' failed
 > make[1]: *** [apps/openssl] Error 1
 > make[1]: Leaving directory '/home/bshpungin/tools/openssl/1.1.1k'
 > Makefile:174: recipe for target 'all' failed
 > make: *** [all] Error 2
 >
 > Can anyone advise what could be the problem and where set_sys_error
 > function/macro is defined?

It's a macro defined in the file e_os.h:

# define set_sys_error(e)        errno=(e)

It's only used in 2 files(crypto/dso/dso_dlfcn.c and crypto/err/err.c),
both of which directly include e_os.h. It's quite strange that the
definition of the macro is not being picked up.

Matt


 >
 > Thanks
 > Robert

Re: Compilation issue with 1.1.1k version

[Matt Caswell]

On 07/04/2021 19:31, Boris Shpoungin via openssl-users wrote:

Hello,

I am using cross compiler toolchain (arm-hisiv200-linux-gnueabi) to 
compile openssl library for arm based custom board.
I had no problems to compile version 1.1.1a, however I am having 
troubles to compile versions 1.1.1i and 1.1.1k:


${LDCMD:-arm-hisiv200-linux-gnueabi-gcc} -pthread -Wa,--noexecstack 
-Wall -O3 -L.   \
-o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o 
apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o 
apps/dsaparam.o apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o 
apps/errstr.o apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o 
apps/ocsp.o apps/openssl.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o 
apps/pkcs8.o apps/pkey.o apps/pkeyparam.o apps/pkeyutl.o apps/prime.o 
apps/rand.o apps/rehash.o apps/req.o apps/rsa.o apps/rsautl.o 
apps/s_client.o apps/s_server.o apps/s_time.o apps/sess_id.o 
apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/storeutl.o 
apps/ts.o apps/verify.o apps/version.o apps/x509.o \

apps/libapps.a -lssl -lcrypto -ldl -pthread
./libcrypto.so: undefined reference to `set_sys_error'
collect2: ld returned 1 exit status
Makefile:6271: recipe for target 'apps/openssl' failed
make[1]: *** [apps/openssl] Error 1
make[1]: Leaving directory '/home/bshpungin/tools/openssl/1.1.1k'
Makefile:174: recipe for target 'all' failed
make: *** [all] Error 2

Can anyone advise what could be the problem and where set_sys_error 
function/macro is defined?


It's a macro defined in the file e_os.h:

# define set_sys_error(e)errno=(e)

It's only used in 2 files(crypto/dso/dso_dlfcn.c and crypto/err/err.c), 
both of which directly include e_os.h. It's quite strange that the 
definition of the macro is not being picked up.


Matt



Thanks
Robert

Re: Using SSL_CTX_set_min_proto_version

[Matt Caswell]

On 07/04/2021 15:22, Tamara Kogan via openssl-users wrote:
I have not found any confirmation in TLS specs that the “record layer” 
version must be 1.0.


I did not mean to imply that the specs say that the record layer version 
*must* be 1.0. Only that that is what OpenSSL *does*.


In fact the earlier versions of the SSL/TLS specs were quite ambiguous 
and unclear on this matter. It is partly for this reason and partly 
because of a proliferation a buggy server implementations that TLS 
version negotiation became the mess that it is today.


The current OpenSSL behaviour was chosen as a result of trying to go 
with the behaviour that gives the maximum interoperability whilst being 
entirely consistent with the specs.


The TLSv1.2 RFC was more explicit about what is allowed for the record 
layer version in the ClientHello message that the earlier versions:


  "TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.  No single value will
   guarantee interoperability with all old servers, but this is a
   complex topic beyond the scope of this document."


TLSv1.3 says something different about it:

   "legacy_record_version:  MUST be set to 0x0303 for all records
generated by a TLS 1.3 implementation other than an initial
ClientHello (i.e., one not generated after a HelloRetryRequest),
where it MAY also be 0x0301 for compatibility purposes.  This
field is deprecated and MUST be ignored for all purposes.
Previous versions of TLS would use other values in this field
under some circumstances."


Our client failed to connect to a mail server when the server changed 
settings and limited  TLS versions to  1.2 only. The server parsed the 
first three bytes of ClientHello, detected 1.0 version and closed the 
connection.


Then, IMO, this server is buggy and not consistent with the TLSv1.2 spec.

Matt

Re: Using SSL_CTX_set_min_proto_version

[Matt Caswell]

On 06/04/2021 18:45, Tamara Kogan via openssl-users wrote:

Hello,

  In our client application we are trying to set TLS 1.2 in ClientHello 
message. The OpenSSL version is 1.1.1h


We use the function

SSL_CTX_set_min_proto_version(ssl->ctx, TLS1_2_VERSION);
If I test the version right after setting it does return 1.2
SSL_CTX_get_proto_version(ssl->ctx) == TLS1_2_VERSION

But the ClientHello is still created with TLS 1.0
(16 03 01 01 42…)

Any explanation why the ClientHello message ignores min TLS version?
Any suggestion how to enforce 1.2 version?


You are looking at the *record layer* TLS version. This is always 1.0 in 
the ClientHello, regardless of what TLS protocol version is actually 
being requested. TLS protocol version fields are a bit of a minefield of 
confusion and unexpected behaviour. For example in an OpenSSL TLSv1.3 
ClientHello the record layer protocol version will be set to TLSv1.0, 
the ClientHello message itself will have the protocol version set to 
TLSv1.2, and the supported versions extension will list the actual 
supported versions (i.e. in your case it would be  TLSv1.3 and TLSv1.2).


Matt

Re: Mismatch between renegotiation reported vs functional

[Matt Caswell]

On 25/03/2021 21:59, Shaun Robbins wrote:
While trying to disable renegotiation the response from openssl reads 
"Secure Renegotiation IS supported" even though renegotiation is failing.


Up until 2009 we just had "Renegotiation" as a concept. Then along came 
a man-in-the-middle attack on such renegotiation. For example see:


https://blog.qualys.com/product-tech/2009/11/05/ssl-and-tls-authentication-gap-vulnerability-discovered

The problem was a fundamental flaw in the design of renegotiation. So 
then RFC5746 was written in order to address this problem. 
Clients/Servers that support RFC5746 are said to support "Secure 
Renegotiation".


Support for secure renegotiation can be indicated via the use of a 
special ciphersuite, or through the use of extensions.


The "Secure Renegotiation IS supported" message means that both peers 
have indicated support for RFC5746. This is entirely independent of 
whether a server will actually *allow* any renegotiation at all. In fact 
it is impossible for the client to know this. The server does not 
indicate it in any way.


So the problem here is a misunderstanding about what this message 
*means*, i.e. it means both peers have indicated support for RFC5746 
(known as "secure renegotiation"). It doesn't tell you whether 
renegotiation will actually work.


Matt




OpenSSL Config:
SSL_set_options(ssl_conn, SSL_OP_NO_RENEGOTIATION);


] $openssl s_client -connect localhost:443 -tls1_2
[SNIP]
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
*Secure Renegotiation IS supported
*Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
[SNIP]
---
HEAD / HTTP/1.1
R
RENEGOTIATING
139845827855680:error:14094153:SSL routines:ssl3_read_bytes:no 
renegotiation:../ssl/record/rec_layer_s3.c:1560:


This article refers to this same problem with some screen shots under 
section "Eliminating a false positive":


https://www.mcafee.com/blogs/enterprise/tips-securing-ssl-renegotiation/ 



Thanks!
--
Shaun Robbins

Re: libcrypto.a and FIPs module in OpenSSL 3.0

[Matt Caswell]

On 26/03/2021 10:47, Bala Duvvuri via openssl-users wrote:

Hi All,

We build the "crypto" code in OpenSSL to generate "libcrypto.a" for MIPs 
platform.

Our application links statically with "libcrypto.a" and uses the OpenSSL crypto 
API's accordingly.

With this compilation model, will it be feasible to integrate with the FIPs 
object module in OpenSSL 3.0?

How can we load the FIPS provider in our application?

(I have gone through the section about the FIPs module installation in 
https://wiki.openssl.org/index.php/OpenSSL_3.0#Platforms)

Any insight will be helpful to me.


It is still possible to use the 3.0 FIPS module even if you use static 
linking to link to libcrypto. However the FIPS module itself is always a 
dynamically loaded shared object (i.e. a .so file).


So, you statically link your application to libcrypto.a. When needed 
(either as a result of config, or an explicit call to 
OSSL_PROVIDER_load()), then the FIPS module fips.so file will be 
dynamically loaded at runtime by libcrypto. How libcrypto is linked to 
the application does not impact its ability to dynamically load the FIPS 
module at runtime.


Matt

Re: ssl client write / server accept seems broken

[Matt Caswell]

On 23/03/2021 15:47, Embedded Devel wrote:
Do you know if your application is statically linked or dynamically 
linked to OpenSSL?

Ive attached the code in question if it helps




Looks like the original developer already tried to print the contents of 
the OpenSSL error stack:


case SSL_ERROR_SSL:
			LOG(LOG_ERR, "%s: Error SSL_ERROR_SSL - return code: %d. %s\n", 
custom_prefix, ret_val, custom_msg);

break;
}

ERR_print_errors_fp(stderr);fflush(stderr);

The errors seem to be going to "stderr" rather than via your "LOG" 
function. You don't show what "LOG" does but if it goes somewhere other 
than stderr then the errors are going somewhere different to your log 
file. Are you able to show us the stderr output from running your 
application?



just compiled with gcc, i see no -lstatic in the makefile ... ive 
attached the ssl .c and .h files in question if you want to see them


What does "ldd" show you for the application binary? i.e.

ldd name-of-you-binary-here


Matt

Re: ssl client write / server accept seems broken

[Matt Caswell]

On 23/03/2021 15:02, Embedded Devel wrote:




IM inclined top think the code for the certs is ok, but  can really say, 
and im not an openssl programmer by any means... just need someone to 
put eyes on the code and fix it really.


The cert looks ok - at least nothing obviously wrong. 2048 bit RSA key.







when i run the client - i get an error on the client side

Tue Mar 23 02:13:58 2021 user.err : ac_ssl_client_write(): Error 
SSL_ERROR_SSL - return code: -1.

Tue Mar 23 02:13:58 2021 user.info : ac_send_init(): Error



It would be useful to see any errors on the OpenSSL error stack which 
might provide more details about specifically what has failed. For 
example you can call the `ERR_print_errors_fp` function to dump the 
error stack to a `FILE *`. Or alternatively use the `ERR_*` functions 
to examine the stack and print it to your log:


Yupp above my head :(


Ah. That's a shame - we could really use understanding the real error 
behind this. "SSL_ERROR_SSL" just means "libssl encountered an error". 
You have to modify your code to print more detailed error information


There doesn't look to be anything obviously wrong from the snippets of 
code that you have shared. I suspect some kind of config issue - but 
without more detailed error information its difficult to say for sure.


Would you be able to get a packet capture of a failing connection? That 
might give us some kind of clue.


Do you know if your application is statically linked or dynamically 
linked to OpenSSL?




and lastly if it helps



Unfortunately, not really. This appears to show a working TLSv1.3 
connection.


Matt

Re: ssl client write / server accept seems broken

[Matt Caswell]

On 23/03/2021 02:37, Embedded Devel wrote:
I have an application previously written for us 10+ years ago that no 
longer seems to be happy


Has something happened that might have caused this? Did you upgrade 
OpenSSL, or do some other kind of update to your code?


Which version of OpenSSL are you using?




and the original dev is no  longer available, so who can i pay to bang 
this out and make it happy, or who can guide me through getting it 
functional... basic info below.


I have a client process which is supposed to speak to a server via ssl, 
and then send data


Ive created a "CA" and generated the CSR / and certs for both the client 
and the server.


What kind of certs did you generate? How big are the keys? Are you able 
to share the certs (not the keys)?




when i run the client - i get an error on the client side

Tue Mar 23 02:13:58 2021 user.err : ac_ssl_client_write(): Error 
SSL_ERROR_SSL - return code: -1.

Tue Mar 23 02:13:58 2021 user.info : ac_send_init(): Error



It would be useful to see any errors on the OpenSSL error stack which 
might provide more details about specifically what has failed. For 
example you can call the `ERR_print_errors_fp` function to dump the 
error stack to a `FILE *`. Or alternatively use the `ERR_*` functions to 
examine the stack and print it to your log:


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

Matt

Forthcoming OpenSSL release

[Matt Caswell]

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL version 1.1.1k.

This release will be made available on Thursday 25th March 2021
between 1300-1700 UTC.

OpenSSL 1.1.1k is a security-fix release. The highest severity issue
fixed in this release is HIGH:
https://www.openssl.org/policies/secpolicy.html#high

Yours

The OpenSSL Project Team

Re: Is SSL_CTX_set_tmp_rsa_callback() only for small keys?

[Matt Caswell]

On 15/03/2021 23:53, Thomas Dwyer III wrote:
I'm porting some very old code from 1.0.2 to 3.0 (but it still has to 
compile for both) and I'm trying to understand it's use of 
SSL_CTX_set_tmp_rsa_callback(). It looks like this was removed in 1.1.0 
but it's not obvious to me why it was necessary in the first place. My 
read of the 1.0.2 man page suggests that the callback is only invoked 
for very small key sizes in order to comply with US export restrictions 
from decades ago, but I'm having trouble confirming this via code 
inspection. Is my understanding correct and, given that this code will 
never see RSA keys smaller than 2048 bits, I can just delete the 
callback rather than add a bunch of:


#if OPENSSL_VERSION_NUMBER < 0x1010L
...
#endif

Or is there some fundamental difference between the way key exchange 
works in 1.0.2 compared to later versions that makes the callback in 
1.0.2 still necessary?


You are correct. Just delete the code.

Matt

Re: Dumping key to file

[Matt Caswell]

On 10/03/2021 13:35, Jeremy Harris wrote:

On 10/03/2021 13:14, Harish Kulkarni wrote:
My application is built along with openssl library source code. We 
want to

dump keys to a file for decrypting TLS flows from network captures.. is
there any flag or environment variable which we can set during building
application or while running application.


Env var SSLKEYLOGFILE


That is not an OpenSSL environment variable (I think that's an NSS thing).

In order to log keys you need to set the key logging callback via 
SSL_CTX_set_keylog_callback.


The callback needs to look like this:

typedef void (*SSL_CTX_keylog_cb_func)(const SSL *ssl, const char *line);

It should write the data provided in "line" to wherever you want to 
store the key data.


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

If you are using the OpenSSL command line then you can use the 
"-keylogfile" option to s_client or s_server to specify the filename for 
where you want keys logged.


Matt

Re: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string

[Matt Caswell]

On 10/03/2021 12:08, Stephen Farrell wrote:

It seems a pity that one has to special case in two ways
there (both keytype and groupname) but I can live with it,


For X25519 you can actually pass a groupname of "x25519" through if you 
want to keep everything consistent. But it's not strictly necessary 
since that is the only group supported by that keytype.


Matt

Re: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string

[Matt Caswell]

On 10/03/2021 00:53, Stephen Farrell wrote:


Hiya,

On 09/03/2021 03:09, Benjamin Kaduk wrote:

I would have expected that the API should hide the differences
other than the group name ... but these APIs are still pretty
new to me, too.  If you can point me at your code I might have
more to say.


So again it's probably my fault but I'm still not seeing the
same behaviour for NIST and non-NIST curves. I made up what
I hope is a fairly simple bit of test code [1] so that might
help clarify where I'm wrong or (less likely) where a change
in the library might be useful.

As I build the test code, the p256 cases seem to work, with
or without the public key, but both 25519 cases fail. In my
(still untidy:-) HPKE code EVP_PKEY_new_raw_private_key
for the non-NIST curves works, but not for NIST curves. So I
have an ok workaround, even if the fault's not mine, which
it of course probably is:-)


Hi Stephen

There are two important things to understand that your code was not 
quite handling correctly:


1) X25519/X448/ED25519/ED448 are treated as different key types to 
"traditional" EC. They really are very different things: different OIDs, 
different standards, different file formats, different key formats etc. 
So while the "traditional" EC curves have the key type "EC", we have 
separate key types of "X25519", "X448", "ED25519" and "ED448"


2) The type of the parameters is dependent on the key type. So a private 
key in "EC" is an integer. But a private key for "X25519" is an octet 
string.


Refer to:

https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-EC.html
https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-X25519.html


I made these changes to your test code to get it to work:

$ diff -u test2evp.c test2evp2.c
--- test2evp.c  2021-03-10 08:47:59.467451154 +
+++ test2evp2.c 2021-03-10 09:03:47.258657721 +
@@ -29,6 +29,7 @@
 #include 

 int bufs2evp(
+const char *keytype,
 char *groupname,
 unsigned char *privbuf, size_t privbuflen,
 unsigned char *pubuf, size_t pubuflen,
@@ -41,38 +42,38 @@
 OSSL_PARAM_BLD *param_bld=NULL;;
 OSSL_PARAM *params = NULL;

-priv = BN_bin2bn(privbuf, privbuflen, NULL);
-if (!priv) {
-erv=__LINE__; goto err;
-}
 param_bld = OSSL_PARAM_BLD_new();
 if (!param_bld) {
 erv=__LINE__; goto err;
 }
 if (pubuf && pubuflen>0) {
-if (OSSL_PARAM_BLD_push_utf8_string(param_bld, "group", 
groupname,0)!=1) {

-erv=__LINE__; goto err;
-}
-if (OSSL_PARAM_BLD_push_BN(param_bld, "priv", priv)!=1) {
-erv=__LINE__; goto err;
-}
 if (OSSL_PARAM_BLD_push_octet_string(param_bld, "pub", pubuf, 
pubuflen)!=1) {

 erv=__LINE__; goto err;
 }
 params = OSSL_PARAM_BLD_to_param(param_bld);
-} else {
-if (OSSL_PARAM_BLD_push_utf8_string(param_bld, "group", 
groupname,0)!=1) {

+}
+if (groupname != NULL && OSSL_PARAM_BLD_push_utf8_string(param_bld, 
"group", groupname,0)!=1) {

+erv=__LINE__; goto err;
+}
+if (strcmp(keytype, "EC") == 0) {
+priv = BN_bin2bn(privbuf, privbuflen, NULL);
+if (!priv) {
 erv=__LINE__; goto err;
-}
+}
 if (OSSL_PARAM_BLD_push_BN(param_bld, "priv", priv)!=1) {
 erv=__LINE__; goto err;
 }
-params = OSSL_PARAM_BLD_to_param(param_bld);
+} else {
+if (OSSL_PARAM_BLD_push_octet_string(param_bld, "priv", 
privbuf, privbuflen)!=1) {

+erv=__LINE__; goto err;
+}
 }
+params = OSSL_PARAM_BLD_to_param(param_bld);
+
 if (!params) {
 erv=__LINE__; goto err;
 }
-ctx = EVP_PKEY_CTX_new_from_name(NULL,"EC", NULL);
+ctx = EVP_PKEY_CTX_new_from_name(NULL,keytype, NULL);
 if (ctx == NULL) {
 erv=__LINE__; goto err;
 }
@@ -167,7 +168,7 @@
  * First do a p-256 one that works, then an x25519 one that does not.
  */

-rv=bufs2evp("P-256",nprivbuf,nprivlen,npubbuf,npublen,&retkey);
+rv=bufs2evp("EC","P-256",nprivbuf,nprivlen,npubbuf,npublen,&retkey);
 if (rv==1) {
 printf("P-256 with key pair worked\n");
 } else {
@@ -175,7 +176,7 @@
 }
 EVP_PKEY_free(retkey);retkey=NULL;

-rv=bufs2evp("P-256",nprivbuf,nprivlen,NULL,0,&retkey);
+rv=bufs2evp("EC","P-256",nprivbuf,nprivlen,NULL,0,&retkey);
 if (rv==1) {
 printf("P-256 with just private key worked\n");
 } else {
@@ -183,7 +184,7 @@
 }
 EVP_PKEY_free(retkey);retkey=NULL;

-rv=bufs2evp("X25519",xprivbuf,xprivlen,xpubbuf,xpublen,&retkey);
+rv=bufs2evp("X25519",NULL,xprivbuf,xprivlen,xpubbuf,xpublen,&retkey);
 if (rv==1) {
 printf("X25519 with key pair worked\n");
 } else {
@@ -191,7 +192,7 @@
 }
 EVP_PKEY_free(retkey);retkey=NULL;

-rv=bufs2evp("X25519",xprivbuf,xprivlen,NULL,0,&retkey);
+rv=bufs2evp("X25519",NULL,xprivbuf,xprivlen,NULL,0,&retkey);
 if (rv==1) {
 

Re: Openssl_3.0.0 stable release

[Matt Caswell]

On 17/02/2021 09:28, Nagarjun J wrote:
> Any one have idea when openssl-3.0.0 stable version can be expected?

We don't have a definitive date at the moment. IMO we are still some
months away from beta1.

Matt

Re:

[Matt Caswell]

On 16/02/2021 19:40, Nagarjun J wrote:
> How to verify if the application is using fips provider from
> openssl-3.0.0 ( similar to fips_mode() api in openssl-fips-2.0.16) 

Using the FIPS provider in Openssl 3.0 works quite differently to the
old FIPS module. There isn't a one-to-one correspondence to the old APIs.

I suggest you make sure you read the 3.0 wiki page to get a good
understand about how it works:

https://wiki.openssl.org/index.php/OpenSSL_3.0

There are a number of ways to ensure that you are always using the FIPS
provider (for example by ensuring that that is the only provider that is
loaded). It's also possible to have multiple providers loaded but using
properties to ensure that only FIPS algorithms are ever selected.

If you use properties to control this then you can use
EVP_default_properties_enable_fips() to set the default global
properties to "fips=yes". You can then also use
EVP_default_properties_is_fips_enabled() to check whether the default
properties are set to "fips=yes".

> and
> does fips provider do run time check and through error if application
> using non fips ciphers.

When you attempt to use a cipher then libcrypto will attempt to find a
suitable one from the available providers that have been loaded based on
any property query string that is being used. As long as you configure
things in the right way (as per the  various options described in the
wiki page above) then you will only have fips validated ciphers loaded
and that match the property query. If you attempt to use some other
non-validated cipher then libcrypto would throw and error because it is
unable to find a matching cipher.

Matt

Forthcoming OpenSSL Release

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL version 1.1.1j.

This release will be made available on Tuesday 16th February 2021
between 1300-1700 UTC.

OpenSSL 1.1.1j is a security-fix release. The highest severity issue
fixed in this release is MODERATE:
https://www.openssl.org/policies/secpolicy.html#moderate

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmAix4IACgkQ2cTSbQ5g
RJEObwgAkM5/Nx3KjqX1Uj69C6b+8Cxx2ijdfei4wQjkVhLqZLteZpKDE0QBAHsV
wGc3cwv1AyPnNfgWvfUwj0k5mRr67fYkz+iAJiNisLc40k0+xPd9F2F804TvKQh2
6HPRY2+AEpQD6nuxJejIOBZruDbFaXRzh1rloQggE9tqUoLslQbYhkrR6BRiePqN
zQarux5yBZDfkQzkaYTDqFH5M6RLrb3w5hlJiJ4uJ1lLz4FNyeUtADofluiIrJuj
zDRZxocOVoyUt2wIZZ+2xhMY894hlilwnBE+fXvWu5d4HakdZkHe4p+HFvP/O0IY
AGn/qXIQfYGt9jH93jCPFdrgO/jvWA==
=ZcL6
-END PGP SIGNATURE-

Re: PKCS12 APIs with fips 3.0

[Matt Caswell]

On 28/01/2021 08:26, Jakob Bohm via openssl-users wrote:
> Does that mean that OpenSSL 3.0 will not have a true "FIPS mode" where
> all the non-FIPS algorithms are disabled, but the FIPS-independent
> schemes/protocols in the "default" provider remains available?
> 
> Remember that in other software systems, such as OpenSSL 1.0.x and MS
> CryptoAPI, FIPS mode causes all non-validated algorithms to fail hard,
> so all higher level operations are guaranteed to use only FIPS-validated
> crypto.

In 3.0 all crypto algorithms are moved to providers. Higher level
features such as CMS and TLS etc remain in libcrypto/libssl.

Applications can load the providers that they want to use for any given
situation. To simulate the way that 1.0.x worked in FIPS mode then they
can choose to *only* load the FIPS provider which will guarantee that no
non FIPS-validated crypto can be used.

Alternatively they can have both FIPS and non-FIPS crypto providers
loaded and available at the same time and swap between them as required
for the context.

More details of how this works are on the 3.0 wiki page here:

https://wiki.openssl.org/index.php/OpenSSL_3.0

In particular section 7 of the above page discusses the various options
you have for using FIPS validated crypto.

Matt


> 
> On 2021-01-27 02:01, Dr Paul Dale wrote:
>> You could set the default property query to "?fips=yes".  This will
>> prefer FIPS algorithms over any others but will not prevent other
>> algorithms from being fetched.
>>
>> Pauli
>>
>> On 27/1/21 10:47 am, Zeke Evans wrote:
>>> I understand that PKCS12 cannot be implemented in the fips provider
>>> but I'm looking for a suitable workaround, particularly something
>>> that is close to the same behavior as 1.0.2 with the fips 2.0 module.
>>>
>>> In my case, the default provider is loaded but I am calling
>>> EVP_set_default_properties(NULL, "fips=yes").  I can wrap calls to
>>> the PKCS12 APIs and momentarily allow non-fips algorithms (ie:
>>> "fips=no" or "provider=default") but that prevents the PKCS12
>>> implementation from using the crypto implementations in the fips
>>> provider.  Is there a property string or some other way to allow
>>> PKCS12KDF in the default provider as well as the crypto methods in
>>> the fips provider?  I have tried "provider=default,fips=yes" but that
>>> doesn't seem to work.
>>>
>>> Using the default provider is probably a reasonable workaround for
>>> reading in PKCS12 files in order to maintain backwards
>>> compatibility.  Is there a recommended method going forward that
>>> would allow reading and writing to a key store while only using the
>>> fips provider?
>>>
>>> Thanks,
>>> Zeke Evans
>>> Micro Focus
>>>
>>> -Original Message-
>>> From: openssl-users  On Behalf Of
>>> Dr Paul Dale
>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>> To: openssl-users@openssl.org
>>> Subject: Re: PKCS12 APIs with fips 3.0
>>>
>>> I'm not even sure that NIST can validate the PKCS#12 KDF.
>>> If it can't be validated, it doesn't belong in the FIPS provider.
>>>
>>>
>>> Pauli
>>>
>>> On 26/1/21 10:48 pm, Tomas Mraz wrote:
>>>> On Tue, 2021-01-26 at 11:45 +, Matt Caswell wrote:
>>>>>
>>>>> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
>>>>>> On 2021-01-25 17:53, Zeke Evans wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>>>>>>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
>>>>>>> provider.  It looks like that is because they try to load PKCS12KDF
>>>>>>> which is not implemented in the fips provider.  These were all
>>>>>>> working in 1.0.2 with the fips 2.0 module.  Will they be supported
>>>>>>> in 3.0 with fips?  If not, is there a way for applications running
>>>>>>> in fips approved mode to support the same functionality and use
>>>>>>> existing stores/files that contain PKCS12 objects?
>>>>>>>
>>>>>>>
>>>>>> This is an even larger issue: Is OpenSSL 3.x so badly designed that
>>>>>> the "providers" need to separately implement every standard or
>>>>>> non-standard combination of algorithm invocati

Re: Default value of a session resumption timeout (300 seconds vs 7200 seconds)

[Matt Caswell]

On 26/01/2021 18:13, Harish Kulkarni wrote:
> Thank you both for bringing this to my attention, your points are
> invaluable.
> 
> If this is something which gets set from server on client side. can
> client override this?. Can i change this to something less and try?. Has
> anyone tried?.
> 
> Whats the option in openssl.conf or some other place?.

The session timeout is something entirely controlled by the server. The
client has no influence on this*. If the server is using session tickets
for its sessions then it provides a lifetime hint to the client to say
how long the client can expect the session to be good for. The client
can query this using SSL_SESSION_get_ticket_lifetime_hint().

On the server the timeout can be configured using SSL_CTX_set_timeout().
I don't think this is possible to change via openssl.conf.

Matt


* Note that the client may be managing a cache of sessions provided by
servers. That's not something that happens by default in OpenSSL but can
be configured using SSL_CTX_set_session_cache_mode(). In that case there
will be separate timeouts associated with the life of the session in the
client cache. Those timeouts may not be the same as the server's timeouts.

> 
> -thanks
> harish
> 
> 
> On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell  <mailto:m...@openssl.org>> wrote:
> 
> 
> 
> On 23/01/2021 15:22, John Thoe wrote:
> > Hi list,
> >
> > The session reuse question posted on the mailing list earlier
> >
> (https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
> > reminded of a somewhat similar question I have.
> >
> > As per the docs,
> >
> https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
> > it says the default value is 300 seconds for which a session resuse
> > will be accepted. The docs say that it is the same for all
> > protocols.
> >
> > However I tried it with my setup where I didn't explicitly set the
> > timeout and I am getting 7200 seconds as the default value. s_client
> > output: TLS session ticket lifetime hint: 7200 (seconds). My client
> > openssl.conf has no setting override (not that it should matter
> > because this is a server preference). No OpenSSL settings on the
> > server have been modified as well.
> 
> Looks to me like the docs are wrong. They probably should say 7200.
> 
> 
> >
> > In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
> > 60 * 5 + 4;   /* 5 minute timeout by default */ ... (with additional
> > four seconds?)
> 
> 
> This gets set during construction and then later overwritten when we
> actually get a new session via "ssl_get_new_session":
> 
>     /* If the context has a default timeout, use it */
>     if (s->session_ctx->session_timeout == 0)
>         ss->timeout = SSL_get_default_timeout(s);
>     else
>         ss->timeout = s->session_ctx->session_timeout;
> 
> In most cases SSL_get_default_timeout() calls tls1_default_timeout() (it
> can end up somewhere different for certain protocol versions - but all
> the different variants are the same!):
> 
> long tls1_default_timeout(void)
> {
>     /*
>      * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too
> long for
>      * http, the cache would over fill
>      */
>     return (60 * 60 * 2);
> }
> 
> 60 * 60 * 2 = 7200
> 
> 
> Matt
> 

Re: PKCS12 APIs with fips 3.0

[Matt Caswell]

On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
> On 2021-01-25 17:53, Zeke Evans wrote:
>>
>> Hi,
>>
>>  
>>
>> Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
>> PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
>> provider.  It looks like that is because they try to load PKCS12KDF
>> which is not implemented in the fips provider.  These were all working
>> in 1.0.2 with the fips 2.0 module.  Will they be supported in 3.0 with
>> fips?  If not, is there a way for applications running in fips
>> approved mode to support the same functionality and use existing
>> stores/files that contain PKCS12 objects?
>>
>>  
>>
> This is an even larger issue: Is OpenSSL 3.x so badly designed
> that the "providers" need to separately implement every standard
> or non-standard combination of algorithm invocations?
> 
> In a properly abstracted design PKCS12KDF would be implemented by
> invoking general EVP functions for underlying algorithms, which
> would in turn invoke the provider versions of those algorithms.

This is exactly the way it works. The implementation of PKCS12KDF
fetches the underlying digest algorithm using whatever providers it has
available. So, for example, if the PKCS12KDF implementation needs to use
SHA256, then it will fetch an available implementation for it - and that
implementation may come from the FIPS provider (or any other provider).

However, in 3.0, KDFs are themselves fetchable cryptographic algorithms
implemented by providers. The FIPS module implements a set of KDFs - but
PKCS12KDF is not one of them. Its only available from the default provider.

So, the summary is, while you can set things up so that all your crypto,
including any digests used by the PKCS12KDF, all come from the FIPS
provider, there is no getting away from the fact that you still need to
have the default provider loaded in order to have an implementation of
the PKCS12KDF itself - which will obviously be outside the module boundary.

There aren't any current plans to bring the implementation of PKCS12KDF
inside the FIPS module. I don't know whether that is feasible or not.

Matt

Re: Default value of a session resumption timeout (300 seconds vs 7200 seconds)

[Matt Caswell]

On 23/01/2021 15:22, John Thoe wrote:
> Hi list,
> 
> The session reuse question posted on the mailing list earlier
> (https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html)
> reminded of a somewhat similar question I have.
> 
> As per the docs,
> https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html,
> it says the default value is 300 seconds for which a session resuse
> will be accepted. The docs say that it is the same for all
> protocols.
> 
> However I tried it with my setup where I didn't explicitly set the
> timeout and I am getting 7200 seconds as the default value. s_client
> output: TLS session ticket lifetime hint: 7200 (seconds). My client
> openssl.conf has no setting override (not that it should matter
> because this is a server preference). No OpenSSL settings on the
> server have been modified as well.

Looks to me like the docs are wrong. They probably should say 7200.


> 
> In ssl/ssl_sess.c#L80, the code matches the document: ss->timeout =
> 60 * 5 + 4;   /* 5 minute timeout by default */ ... (with additional
> four seconds?)


This gets set during construction and then later overwritten when we
actually get a new session via "ssl_get_new_session":

/* If the context has a default timeout, use it */
if (s->session_ctx->session_timeout == 0)
ss->timeout = SSL_get_default_timeout(s);
else
ss->timeout = s->session_ctx->session_timeout;

In most cases SSL_get_default_timeout() calls tls1_default_timeout() (it
can end up somewhere different for certain protocol versions - but all
the different variants are the same!):

long tls1_default_timeout(void)
{
/*
 * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too long for
 * http, the cache would over fill
 */
return (60 * 60 * 2);
}

60 * 60 * 2 = 7200


Matt

Re: Random and rare Seg faults at openssl library level

[Matt Caswell]

On 12/01/2021 04:23, Gimhani Uthpala wrote:
> Hi team,
> https://www.openssl.org/docs/man1.0.2/man3/CRYPTO_set_locking_callback.html
> :  From this , learnt that for openssl multi-threaded applications to be
> run safely, the callback functions to be implemented.
> 
> I am using this in a multi-threaded application and Above scenario was
> again recreated and in that case 2 threads were calling RSA_verify (same
> stack above). However, for SSL_do_handshake, SSL* objects are given
> separately and they are not shared between threads. So, we have not
> implemented callback functions.
> 
> Could you please clarify whether we need to implement locking callbacks
> for multi-threaded applications  even if the ssl objects we supply are
> provided separately for threads?

If you are using 1.0.2 in a multi-threaded context then you *must*
implement the locking callbacks. There are resources that are shared
between multiple threads that require appropriate locking.

Matt



> 
> Many thanks.
> 
> On Wed, Jan 6, 2021 at 10:40 PM Gimhani Uthpala
> mailto:gimhanieuthp...@gmail.com>> wrote:
> 
> Dear team,
> I'm running an application which uses openssl for secure
> communication between processes. I am getting seg-faults at openssl
> level. This only occurred very randomly and the following are stacks
> that seg faults  at openssl level in the given 2 cases. We are using
> openssl 1.0.2k. 
> 
> Went through the security vulnerabilities list for this version but
> couldn't find a clue. Running valgrind too didn't give an exact clue
> related to the issue. Can you please guide me how can I find the
> exact root cause for the seg fault?  
> 
> I am calling SSL_do_handshake(ssl_ctx) from my code level and both
> the below seg faults are occuring from it's inside. 
> 
> #0  0x7fd64cdabdd3 in ASN1_item_verify () from
> /lib64/libcrypto.so.10
> #1  0x7fd64cdcac58 in internal_verify () from /lib64/libcrypto.so.10
> #2  0x7fd64cdccaef in X509_verify_cert () from
> /lib64/libcrypto.so.10
> #3  0x7fd64d111c68 in ssl_verify_cert_chain () from
> /lib64/libssl.so.10
> #4  0x7fd64d0e8cc6 in ssl3_get_client_certificate () from
> /lib64/libssl.so.10
> *#5  0x7fd64d0ea3f8 in ssl3_accept () from /lib64/libssl.so.10*
> 
> 
>  #0 0x7ffb65529854 in RSA_verify () from /usr/lib64/libcrypto.so.10
>  #1 0x7ffb6552f1fc in pkey_rsa_verify () from
> /usr/lib64/libcrypto.so.10
>  #2 0x7ffb65561877 in EVP_DigestVerifyFinal () from
> /usr/lib64/libcrypto.so.10
>  #3 0x7ffb6556af25 in ASN1_item_verify () from
> /usr/lib64/libcrypto.so.10
>  #4 0x7ffb65589c58 in internal_verify () from
> /usr/lib64/libcrypto.so.10
>  #5 0x7ffb6558baef in X509_verify_cert () from
> /usr/lib64/libcrypto.so.10
>  #6 0x7ffb658d1417 in ssl_add_cert_chain () from
> /usr/lib64/libssl.so.10
>  #7 0x7ffb658b6095 in ssl3_output_cert_chain () from
> /usr/lib64/libssl.so.10
>  #8 0x7ffb658ae894 in ssl3_send_client_certificate () from
> /usr/lib64/libssl.so.10
> * #9 0x7ffb658aeecf in ssl3_connect () from /usr/lib64/libssl.so.10
>  #10 0x7ffb658b8e7e in ssl23_connect () from
> /usr/lib64/libssl.so.10*
> 
>   I am setting context to use SSLv23_method() s. However, I can see
> ssl3_ methods being called. Is there any issue with that?  
> 
> Given below is SSL* object passed to SSL_do_handshake method.
> 
> (gdb) p *p_SSLCtx
> $2 = {version = 771, type = 4096, method = 0x7ffb65af3320, rbio =
> 0x7ffb5819e140, wbio = 0x7ffb58193570, bbio = 0x7ffb58193570,
> rwstate = 1, in_handshake = 2, *handshake_func = 0x7ffb658aea30
> *, server = 0, new_session = 0, quiet_shutdown = 0,
> shutdown = 0, state = 4467,
>   rstate = 240, init_buf = 0x7ffb581934b0, init_msg =
> 0x7ffb581e10d4, init_num = 0, init_off = 0, *packet = 0x7ffb581e6633
> "\026\003\003", packet_length = 0*, s2 = 0x0, s3 = 0x7ffb58195ee0,
> d1 = 0x0, read_ahead = 0, msg_callback = 0x0, msg_callback_arg =
> 0x0, hit = 0, param = 0x7ffb581933f0,
>   cipher_list = 0x0, cipher_list_by_id = 0x0, mac_flags = 0,
> enc_read_ctx = 0x0, read_hash = 0x0, expand = 0x0, enc_write_ctx =
> 0x0, write_hash = 0x0, compress = 0x0, cert = 0x7ffb58195ba0,
> sid_ctx_length = 0, sid_ctx = '\000' , session =
> 0x7ffb58198100,
>   generate_session_id = 0x0,..
>  
> 
> 
> -- 
> *Gimhani Uthpala Kankanamge*
> 
> 
> 
> -- 
> *Gimhani Uthpala Kankanamge*

Re: SSL_CONF_cmd(): SecurityLevel keyword, by chance?

[Matt Caswell]

Please raise your patch as a PR so that it can properly reviewed. You'll
also need to submit a CLA:

https://www.openssl.org/policies/cla.html

Thanks

Matt


On 11/01/2021 22:19, Steffen Nurpmeso wrote:
> Hello.
> 
> Matt Caswell wrote in
>  :
>  |On 09/01/2021 23:24, Steffen Nurpmeso wrote:
>  |> Hello.
>  |>
>  |> I do use SSL_CONF_cmd() (and modules) possibility if it exists,
>  |> since it allow users to simply use the features of the newest
>  |> OpenSSL library without any code changes on my side.
>  |> This is great, and i think i applauded in the past.
>  |>
>  |> I discovered security_level(), needless to say i thought
>  |> @SECLEVEL= of ciphers(1) was broken until i discovered -s is
>  |> required to make it functional (..and do not get me started on
>  |> -ciphersuites..).
>  |>
>  |> Wouldn't it make sense to offer SecurityLevel as a keyword for
>  |> SSL_CONF_cmd(), and therefore also SSL_CTX_config(), too -- since
>  |> it seems (from the manual) to extend to more than what i would
>  |> assume to be covered by a @SECLEVEL member of CipherString aka
>  |> ..Ciphersuites...?
>  |
>  |This is probably a good idea. I'd support it if someone wanted to add that.
> 
> Please find a simple add-on attached, it could be it ("having no
> idea of the codebase"..).  It compiles, but when linking against
> 678cae0295e3f (master from today) plus the patch i get errors:
> 
>   In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected declaration 
> specifiers or '...' before 'ossl_check_const_GENERAL_NAME_sk_type'
> 402 |DEFINE_STACK_OF(GENERAL_NAME)
> |^~~
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before 
> '*' token
> 402 |DEFINE_STACK_OF(GENERAL_NAME)
> |^~~
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before 
> 'OPENSSL_sk_value'
> 402 |DEFINE_STACK_OF(GENERAL_NAME)
> |^~~
>   In file included from 
> /home/steffen/usr-kent-linux-x86_64/opt/.ossl3/include/openssl/crypto.h:35,
>from /home/steffen/src/nail.git/src/mx/xtls.c:53:
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected identifier 
> or '(' before 'struct'
> 402 |DEFINE_STACK_OF(GENERAL_NAME)
> |^~~
>   In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:4: error: expected ')' before 
> 'OPENSSL_sk_new'
> 402 |DEFINE_STACK_OF(GENERAL_NAME)
> |^~~
>   /home/steffen/src/nail.git/src/mx/xtls.c:402:1: error: macro 
> "sk_GENERAL_NAME_new_null" passed 1 arguments, but takes just 0
> 402 |DEFINE_STACK_OF(GENERAL_NAME)
> | ^  ~
>   In file included from /home/steffen/src/nail.git/src/mx/xtls.c:60:
>   
> /home/steffen/usr-kent-linux-x86_64/opt/.ossl3/include/openssl/x509v3.h:225: 
> note: macro "sk_GENERAL_NAME_new_null" defined here
> 225 | #define sk_GENERAL_NAME_new_null() ((STACK_OF(GENERAL_NAME) 
> *)OPENSSL_sk_new_null())
> |
> 
> I have not tested OpenSSL 3.0 for a while, but it was clean when
> i tried it last, my last commit was "Be truly
> OPENSSL_NO_DEPRECATED_3_0 clean" on 2020-07-19.  I used
> 
>   ./config --prefix=/home/steffen/usr-kent-linux-x86_64/opt/.ossl3 \
> zlib-dynamic shared no-deprecated no-async threads no-tests \
> -Wl,-rpath,'$(LIBRPATH)'
> 
> on a current glibc Linux (CRUX-Linux 3.6).
> 
> Ciao from Germany,
> 
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> 

Re: SSL_CONF_cmd(): SecurityLevel keyword, by chance?

[Matt Caswell]

On 09/01/2021 23:24, Steffen Nurpmeso wrote:
> Hello.
> 
> I do use SSL_CONF_cmd() (and modules) possibility if it exists,
> since it allow users to simply use the features of the newest
> OpenSSL library without any code changes on my side.
> This is great, and i think i applauded in the past.
> 
> I discovered security_level(), needless to say i thought
> @SECLEVEL= of ciphers(1) was broken until i discovered -s is
> required to make it functional (..and do not get me started on
> -ciphersuites..).
> 
> Wouldn't it make sense to offer SecurityLevel as a keyword for
> SSL_CONF_cmd(), and therefore also SSL_CTX_config(), too -- since
> it seems (from the manual) to extend to more than what i would
> assume to be covered by a @SECLEVEL member of CipherString aka
> ..Ciphersuites...?

This is probably a good idea. I'd support it if someone wanted to add that.

Matt

Re: How to set amount of salt for PBKDF2/PKCS8 keys?

[Matt Caswell]

On 08/01/2021 00:59, Mathias Ricken wrote:
> How do I sell openssl to use more salt when generating the private key?

Unfortunately the pkcs8 tool does not support setting a custom salt
length and always uses the default length of 64 bits.

The best I can offer you is a hack of the tool to change the default to
128 bits (16 bytes):

diff --git a/apps/pkcs8.c b/apps/pkcs8.c
index 205536560a..14700e5d12 100644
--- a/apps/pkcs8.c
+++ b/apps/pkcs8.c
@@ -229,7 +229,7 @@ int pkcs8_main(int argc, char **argv)
 scrypt_N, scrypt_r,
scrypt_p);
 else
 #endif
-pbe = PKCS5_pbe2_set_iv(cipher, iter, NULL, 0, NULL,
+pbe = PKCS5_pbe2_set_iv(cipher, iter, NULL, 16, NULL,
 pbe_nid);
 } else {
 pbe = PKCS5_pbe_set(pbe_nid, iter, NULL, 0);



Matt

Re: Random and rare Seg faults at openssl library level

[Matt Caswell]

On 06/01/2021 17:10, Gimhani Uthpala wrote:
>   I am setting context to use SSLv23_method() s. However, I can see
> ssl3_ methods being called. Is there any issue with that?  

Just answering this one side question: no, this is normal behaviour.

Matt

Re: openssl fips patch for RSA Key Gen (186-4)

[Matt Caswell]

On 05/01/2021 11:41, y vasavi wrote:
> 
> Hi All,
> 
> We currently FOM 2.0 module for FIPS certification.
> It doesn't have support for RSA Key generation(186-4)
> 
> Are there any patches available ?

Definitely there are no official ones (I'm also not aware of any
unofficial ones).

The 3.0 module which will be part of OpenSSL 3.0 when it is released
supports 186-4 RSA Key gen.

Matt



> 
> Thanks,
> Vasavi.

Re: Format error in certificate´s notAfter field

[Matt Caswell]

On 22/12/2020 17:43, Raúl Uría Elices wrote:
> Hi,
> 
> I´m trying to connect to my vpn server, using tunnelblick, but thinking
> this is a openssl stuff... may be I am wrong.
> 
> 
> When connecting I got (XX is a placeholder) : 
> 
> 2020-12-22 17:32:49.423703 VERIFY ERROR: depth=0, error=format error in
> certificate's notAfter field: C=es, L=P, O=XX, CN=XX,
> emailAddress=XX, serial=17702460327850242852
> 
> I have checked this:
> https://mta.openssl.org/pipermail/openssl-users/2019-March/010018.html ,
> but seems to be something different.
> 
> When checking UTC field for server CA cert, I got:
> 
> % openssl asn1parse -in ca.crt  | grep UTC
>   207:d=3  hl=2 l=  13 prim: UTCTIME   :170908154452Z
>   222:d=3  hl=2 l=  13 prim: UTCTIME   :360718151218Z

I don't see anything obviously wrong with those encodings. Are you
willing to share the actual certificate?

Matt

Re: openssl asym_cipher/signature provider

[Matt Caswell]

On 14/12/2020 16:04, Thulasi Goriparthi wrote:
> Hello,
> 
> Is it acceptable for an openssl provider to implement an algorithm
> (rsaEncryption) as asym_cipher or signature algorithm without
> implementing corresponding keymgmt or redirecting the same to the
> 'default' provider?
> 
> I ask, as our engine implementation handles key import dynamically at
> time of offloading crypto operation, using ex_data of key objects. I
> want to quickly upgrade this to a provider to convince myself that the
> basic upgrade from engine to provider isn't time consuming.

One of the main purposes of the key manager is to import the key into
the provider into a form that it can use internally. The
asym_cipher/signature implementations just use references to keys
created by the key manager.

So unfortunately it is necessary to have a key manager in order for a
provider to have a usable asym_cipher or signature implementation.

Note: it does not have to be a fully featured key manager, e.g. it does
not need to implement key generation. It would be perfectly possible to
have key generation done in some other key manager and then subsequently
import it into the target key manager.

Matt

Re: DH_generate_key

[Matt Caswell]

On 10/12/2020 16:14, Narayana, Sunil Kumar wrote:
> Hi Matt,
> 
>     Thanks for the code sample. we understood the end to end
> flow to generate the DH key.
> 
> I wanted to understand one more aspect here, In our application we were
> obtaining two keys (pub_key/ priv_key) from the DH_generate_key() with
> single values of  dh->p/ dh->g.
> 
> But now in 3.0 equivalent, I guess we can get only one key from the p/g
> params right ? how to get equivalent pub_key / priv_key ? please suggest.


An EVP_PKEY can hold either a priv/public key pair, or just a public key
(or just parameters) depending on the context.

In this case, after a successful call to EVP_PKEY_gen() it will hold the
priv/public key pair.

In many cases you don't need to get the private key out. Often DH keys
are "ephemeral", i.e. they are only ever used for one key exchange, and
are only ever held in memory. If you are doing a "non-ephemeral" key
exchange then you may still need to get it out.

There are a number of ways to do this depending on what you want to achieve.

You can write the whole DH priv/pub key pair out to a PEM file to later
load back in again using the OSSL_ENCODER API, e.g.

OSSL_ENCODER_CTX *ectx
= OSSL_ENCODER_CTX_new_by_EVP_PKEY(pkey, OSSL_KEYMGMT_SELECT_ALL,
   "PEM", NULL, NULL);
OSSL_ENCODER_to_bio(ectx, out);

Alternatively if you want the "raw" octet bytes for the public key you
can use

size_t len = 0;
unsigned char *pub;

EVP_PKEY_get_raw_public_key(pkey, NULL, &len);
pub = OPENSSL_malloc(len);
EVP_PKEY_get_raw_public_key(pkey, pub, &len);

Similarly you can use EVP_PKEY_get_raw_private_key() to get the raw
private key.

Finally, if you just want to get the public key out to send to the peer
you can use EVP_PKEY_get1_encoded_public_key():

unsigned char *buf = NULL;

EVP_PKEY_get1_encoded_public_key(pkey, &buf);
/* Do stuff with buf */
OPENSSL_free(buf);

For DH this works in a similar way to EVP_PKEY_get_raw_public_key(). It
produces a format suitable for use in TLSv1.2 and CMS...which is
actually just the raw public key. For key types other than DH it may not be.

Note: for brevity above I've omitted error handling from the code
samples. You should be sure to add that.

Matt



> 
>  
> 
>  
> 
> Regards,
> 
> Sunil
> 
> *From:*openssl-users  *On Behalf Of
> *openssl-users-requ...@openssl.org
> *Sent:* 10 December 2020 17:46
> *To:* openssl-users@openssl.org
> *Subject:* openssl-users Digest, Vol 73, Issue 9
> 
>  
> 
> 
> 
> NOTICE: This email was received from an EXTERNAL sender
> 
> 
> 
> 
> Send openssl-users mailing list submissions to
> openssl-users@openssl.org <mailto:openssl-users@openssl.org>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> openssl-users-requ...@openssl.org <mailto:openssl-users-requ...@openssl.org>
> 
> You can reach the person managing the list at
> openssl-users-ow...@openssl.org <mailto:openssl-users-ow...@openssl.org>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
> 
> 
> Today's Topics:
> 
> 1. Re: DH_generate_key (Matt Caswell)
> 2. Re: creating certificate by code / problems to load via
> openssl x509 / pem format (Andreas Tengicki)
> 3. Re: creating certificate by code / problems to load via
> openssl x509 / pem format (Tomas Mraz)
> 4. Re: DH_generate_key (Matt Caswell)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 9 Dec 2020 15:31:51 +
> From: Matt Caswell mailto:m...@openssl.org>>
> To: "Narayana, Sunil Kumar"  <mailto:sanaray...@rbbn.com>>,
> "openssl-users@openssl.org <mailto:openssl-users@openssl.org>"
> mailto:openssl-users@openssl.org>>
> Subject: Re: DH_generate_key
> Message-ID: <72867e9d-4e91-faa0-d329-1f92ed723...@openssl.org
> <mailto:72867e9d-4e91-faa0-d329-1f92ed723...@openssl.org>>
> Content-Type: text/plain; charset=utf-8
> 
> 
> 
> On 08/12/2020 17:43, Narayana, Sunil Kumar wrote:
>> Dear openssl team,
>>
>> ?
>>
>> ??? While migrating from 1.0.2 to 3.0, ?we found that
>> DH_generate_key() has be deprecated. And as per the man page, it is
>> advised to use EVP_PKEY_derive_init
>> <https://www.openssl.org/docs/manmaster/man3/EVP_PK

Re: DH_generate_key

[Matt Caswell]

On 09/12/2020 15:31, Matt Caswell wrote:
>> our application creates a new DH and using DH_generate_key()
> 
> How do you set up the DH parameters? Do you load them from a file or
> generate them in your application? Or some other way? Will it break your
> application if you swap to using different parameters, or must you
> retain support for the old ones?
> 
> The first step is to create an EVP_PKEY object containing the DH
> parameters. How to do that depends on the answers to the above questions.

Sunil emailed me directly (off list) and provided some code samples.

So you have some fixed "p" and "g" parameter values defined as static
unsigned char arrays, which you are currently converting to BIGNUMs
using "BN_bin2bn", and then assigning to "dh->p" and "dh->g" respectively.

The "g" value is just "2", so in the 3.0 equivalent you don't need to
convert that to a BIGNUM first. Some equivalent code to construct a DH
params object (called "param_key" in the code below) is:


EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_from_name(NULL, "DH", NULL);
OSSL_PARAM_BLD *tmpl = NULL;
OSSL_PARAM *params = NULL;
EVP_PKEY *param_key = NULL;

if (pctx == NULL || !EVP_PKEY_key_fromdata_init(pctx))
goto err;

if ((tmpl = OSSL_PARAM_BLD_new()) == NULL
|| !OSSL_PARAM_BLD_push_BN(tmpl, OSSL_PKEY_PARAM_FFC_P, p)
|| !OSSL_PARAM_BLD_push_uint(tmpl, OSSL_PKEY_PARAM_FFC_G, 2))
goto err;

params = OSSL_PARAM_BLD_to_param(tmpl);
if (params == NULL || !EVP_PKEY_fromdata(pctx, ¶m_key, params))
goto err;
 err:
EVP_PKEY_CTX_free(pctx);
OSSL_PARAM_BLD_free_params(params);
OSSL_PARAM_BLD_free(tmpl);


You can then generate the key using the code sample I gave in my
previous email:

EVP_PKEY *key = NULL;
EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_pkey(NULL, param_key, NULL);

EVP_PKEY_keygen_init(gctx);
EVP_PKEY_gen(gctx, &key);
EVP_PKEY_print_private(bio_out, key, 0, NULL);
...
EVP_PKEY_free(key);
EVP_PKEY_CTX_free(gctx);



Hope that helps,

Matt

Re: DH_generate_key

[Matt Caswell]

On 08/12/2020 17:43, Narayana, Sunil Kumar wrote:
> Dear openssl team,
> 
>  
> 
>     While migrating from 1.0.2 to 3.0,  we found that
> DH_generate_key() has be deprecated. And as per the man page, it is
> advised to use EVP_PKEY_derive_init
> 
>  & EVP_PKEY_derive
> 
> 

The reference to EVP_PKEY_derive_init/EVP_PKEY_derive is a bit
misleading, because those are replacements for DH_compute_key() not
DH_generate_key().

The equivalents for DH_generate_key() are EVP_PKEY_keygen_init() and
EVP_PKEY_gen().

https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_gen.html



> our application creates a new DH and using DH_generate_key()

How do you set up the DH parameters? Do you load them from a file or
generate them in your application? Or some other way? Will it break your
application if you swap to using different parameters, or must you
retain support for the old ones?

The first step is to create an EVP_PKEY object containing the DH
parameters. How to do that depends on the answers to the above questions.


> creates
> pub_key/priv_key and uses it. how can we replace this exactly with EVP.
> 


As noted by Daniel in this response to your question there are examples
on the EVP_PKEY-DH manual page.

https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-DH.html

Assuming you have set up the parameters in an EVP_PKEY object
(param_key) then this is the relevant example:


EVP_PKEY *key = NULL;
EVP_PKEY_CTX *gctx = EVP_PKEY_CTX_new_from_pkey(NULL, param_key, NULL);

EVP_PKEY_keygen_init(gctx);
EVP_PKEY_gen(gctx, &key);
EVP_PKEY_print_private(bio_out, key, 0, NULL);
...
EVP_PKEY_free(key);
EVP_PKEY_CTX_free(gctx);


This gives you a generated DH key in the "key" object.


Matt


> And please suggest what EVP API’s should we use to generate pub/priv keys ?
> 
>  
> 
> _Application code_
> 
> _ _
> 
>     dh = DH_new();
> 
>     dh->p = BN_bin2bn(modSize, octet_len, NULL);
> 
>     dh->g = BN_bin2bn(H235Bits_generator, H235Bits_generator_len / 8, NULL);
> 
>  
> 
>     if ( ! DH_generate_key(dh) )
> 
>     {
> 
>     return FAILURE;
> 
>     }
> 
>     n = (unsigned) BN_num_bytes(dh->pub_key);
> 
>   
> 
> BN_bn2bin(dh->pub_key, p);
> 
>     n = (unsigned) BN_num_bytes(dh->priv_key);
> 
>  
> 
>  
> 
> Instead above logic can we do this ? is derive generated pub/priv keys ?
> 
>  
> 
> //create ctx
> 
> Ctx = EVP_PKEY_CTX_new_from_name (NULL, “DM”, NULL);
> 
> EVP_PKEY_derive_init (ctx)
> 
>  
> 
>  
> 
> Regards,
> 
> Sunil
> 
> 
> 
> 
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all
> copies, including any attachments.
> 

Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

[Matt Caswell]

On 09/12/2020 11:35, Craig Henry wrote:
> Hi,
> 
> This is my first post to this list so please be kind!
> 
> Environment - Linux Centos
> SSL - 1.0.2k19-el7
> 
> Connection - CURL (via PHP) with public / private key auth + http basic auth
> 
> We're having an issue where we are seeing intermittent behavior
> connecting to a 3rd party of the key being rejected with a 8152 error -
> "The key does not support the requested operation". Other times it works
> OK.

That error does not come from OpenSSL. It appears to be an NSS error. So
I'd suggest asking on an NSS or CURL forum.

Matt



> 
> We have another user who is using this 3rd party and same connection
> type but not reported this issue.
> 
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?
> 
> The CURL logs are below but altered for privacy reasons.
> 
> Thanks
> 
> 
> 
> -Craig
> 
> 
> 
> 
> 
> 
> 
> *Key blocked response*
> 
> * About to connect() to  port 443 (#96)
> *   Trying XX
> * Connected to XX (X) port 443 (#96)
> *   CAfile: /X_tlstrust.pem
> 
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=XXX
> ,O=,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name:  
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user ''
>> POST /XX/services HTTP/1.1
> Authorization: Basic X
> Host:  
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name: 
> * issuer: CN=XX ,O= GmbH,L=Bad
> Vilbel,ST=Hessen,C=DE
> * SSL read: errno -8152 (SEC_ERROR_INVALID_KEY)
> * The key does not support the requested operation.
> * Closing connection 96
> 
> 
> *Successful response*
> 
> * About to connect() to XX port 443 (#81)
> *   Trying xxx...
> * Connected to   (XX) port 443 (#81)
> *   CAfile:
> /X
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=www.
> ,O=XXn,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: XXX
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user 'X'
>> POST /X/services HTTP/1.1
> Authorization: Basic 
> Host: X 
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
> 
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=,OU=Buntingford,O=XX Ltd,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name:X
> * issuer: CN=X ,O=,L=Bad
> Vilbel,ST=Hessen,C=DE
> < HTTP/1.1 500
> < Date: Tue, 08 Dec 2020 13:42:26 GMT
> < Server: Apache
> < Strict-Transport-Security: max-age=63072000; includeSubdomains
> < X-XSS-Protection: 1; mode=block
> < X-Content-Type-Options: nosniff
> < Cache-Control: no-cache, no-store, must-revalidate
> < Pragma: no-cache
> < X-Frame-Options: SAMEORIGIN
> < Content-Security-Policy: default-src 'self' *.googleapis.com
>  *.klarna.com 
> *.masterpass.com  *.mastercard.com
>  *.npci.org.in  'unsafe-eval'
> 'unsafe-inline'; frame-ancestors 'self'
> < X-Application-Context: application:spring-boot,node-global,node-api:8843
> < Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
> < SOAPAction: ""
> < Expires: 0
> < Content-Type: text/xml;charset=utf-8
> < Content-Length: 1481
> < Set-Cookie: JSESSIONID=8778DF260AA5C9E0AAB3E1E4C572453D.ipg_api_k8s;
> Path=/X; Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
> < Connection: close
> <
> * Closing connection 81
> 
> 
> 
> 
> 
> *Development Team*
> 
> *tassolutions *
> the attic | south suite | fullbridge mill | maldon | essex | cm9 4le | UK
> 
> *tel:*   +44 (0)1621 857785   -
> *www.tas-solutions.co.uk *
> 
> *Our business | support hours are Monday - Frida

Re: Use OpenSSL to decrypt TLS session from PCAP files

[Matt Caswell]

On 08/12/2020 15:28, Oren Shpigel wrote:
> Hi, thanks for the answer.
> 
> I know wireshark and ssldump have this capability, but I'm looking for a
> way to do it in my own software in C++, (using OpenSSL, if possible, but
> open to other suggestions as well).

Unfortunately OpenSSL does not support this capability. It obviously
supports all the required low-level crypto primitives to do it - but you
would have to put them together yourself, as well as do all the packet
parsing, etc. This would be ... difficult. :-)

Matt


> 
> On Tue, Dec 8, 2020 at 4:32 PM Dr. Matthias St. Pierre
> mailto:matthias.st.pie...@ncp-e.com>> wrote:
> 
> Do you need to integrate the decryption into your own software, or
> are you just looking for a possibility to monitor and view the
> traffic?
> 
> If it’s the latter, try and take a look at the SSL decryption
> support that Wireshark provides. 
> 
> __ __
> 
> https://wiki.wireshark.org/TLS
> 
> https://www.comparitech.com/net-admin/decrypt-ssl-with-wireshark/
> 
> __ __
> 
> __ __
> 
> hth,
> 
> Matthias
> 
> __ __
> 
> Disclaimer: I haven’t used it for TLS myself, only for IPsec, and I
> can’t tell how up-to-date it is, in particular whether it is TLS 1.3
> ready.
> 
> __ __
> 
>  
> 
> *NCP engingeering GmbH*   **  *Dr. Matthias St. Pierre*
> 
> Senior Software Engineer
> matthias.st.pie...@ncp-e.com 
> Phone: +49 911 9968-0
> www.ncp-e.com 
> 
> *
> Follow us on:* Facebook  |
> Twitter  | Xing
>  | YouTube
>  | LinkedIn
> 
> 
> 
> *Headquarters Germany: *NCP engineering GmbH • Dombuehler Str. 2 •
> 90449 • Nuremberg
> *North American HQ:* NCP engineering Inc. • 601 Cleveland Str.,
> Suite 501-25 • Clearwater, FL 33755
> 
> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate
> Dietrich
> Registry Court: Lower District Court of Nuremberg
> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.:
> DE 133557619
> 
> This e-mail message including any attachments is for the sole use of
> the intended recipient(s) and may contain privileged or confidential
> information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> please immediately contact the sender by reply e-mail and delete the
> original message and destroy all copies thereof.
> 
> 
> 
> 
> 
> *From**:*openssl-users  > *On Behalf Of *Oren Shpigel
> *Sent:* Tuesday, December 8, 2020 3:15 PM
> *To:* openssl-users@openssl.org 
> *Subject:* Use OpenSSL to decrypt TLS session from PCAP files
> 
> __ __
> 
> Hi, 
> 
> I generated a PCAP file with TLS session, and I have the matching
> private key used by my HTTPS server.
> The TLS session is not using DH for key exchange, so it should be
> possible to decrypt.
> I know OpenSSL can be used to connect to a socket to "actively"
> handle the TLS session, but is there a way to "passively" decode and
> decrypt a session?
> How can I "feed" the packets (both directions) into the OpenSSL
> library?
> 
> Thanks!
> 

Re: Regarding #def for 'SSL_R_PEER_ERROR_NO_CIPHER' and 'SSL_R_NO_CERTIFICATE_RETURNED' in openssl3.0

[Matt Caswell]

On 07/12/2020 14:26, Jakob Bohm via openssl-users wrote:
>>> error: 'SSL_R_PEER_ERROR_NO_CIPHER' was not declared in this scope
>> This one was only ever used in the SSLv2 implementation. Since no one
>> uses SSLv2 any more and it is considered highly insecure its
>> implementation was removed some while ago. So the reason code was also
>> deleted.
> So what error is returned by SSL3/TLS1.x when the client (erroneously)
> offers an empty cipher list?

Offering no ciphers at all would actually be a protocol error (since the
RFCs require at least one ciphersuite to be sent). We actually treat it
the same way as if none of the clients offered ciphersuites match with
the server's list. The error in this case is SSL_R_NO_SHARED_CIPHER.

Matt

Re: Regarding #def for 'SSL_R_PEER_ERROR_NO_CIPHER' and 'SSL_R_NO_CERTIFICATE_RETURNED' in openssl3.0

[Matt Caswell]

On 04/12/2020 13:28, Narayana, Sunil Kumar wrote:
> Hi,
> 
>     We are trying to upgrade our application from openssl
> usage of 1.0.2 to openssl 3.0, during which we observe following errors.
> 
> Looks like the below #def been removed from 1.1 onwards, Should
> application also need to take off from its usage ? or is there any
> alternative to be used in application ?

1.0.x -> 1.1.x is a breaking change, and so is 1.1.x to 3.0. Return
codes are liable to change in these upgrades.

> error: 'SSL_R_PEER_ERROR_NO_CIPHER' was not declared in this scope

This one was only ever used in the SSLv2 implementation. Since no one
uses SSLv2 any more and it is considered highly insecure its
implementation was removed some while ago. So the reason code was also
deleted.

> error: 'SSL_R_NO_CERTIFICATE_RETURNED' was not declared in this scope

This reason code existed in 1.0.2 but was never used by anything.

Matt

Fwd: Forthcoming OpenSSL Release

[Matt Caswell]

FYI


 Forwarded Message 
Subject: Forthcoming OpenSSL Release
Date: Tue, 1 Dec 2020 04:15:51 -0600
From: Paul Nelson 
Reply-To: openssl-users@openssl.org
To: openssl-annou...@openssl.org

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.1.1i.

This release will be made available on Tuesday 8th December 2020 between
1300-1700 UTC.

OpenSSL 1.1.i is a security-fix release. The highest severity issue
fixed in this release is HIGH:
https://www.openssl.org/policies/secpolicy.html#high

Yours

The OpenSSL Project Team

Re: HMAC is deprecated in 3.0 getting error 'HMAC' was not declared in this scope

[Matt Caswell]

On 26/11/2020 17:32, Narayana, Sunil Kumar wrote:
> Error2 : error: invalid use of incomplete type 'SSL' {aka 'struct
> ssl_st'} ssl->d1->mtu = MAX_SEND_PKT_SIZE;

Use SSL_set_mtu(ssl, MAX_SEND_PKT_SIZE) instead.

Matt

Re: set/get utilities are not available to access variable 'num' of structure bio_st (Matt Caswell)

[Matt Caswell]

On 23/11/2020 11:28, Narayana, Sunil Kumar wrote:
> Hi Matt,
>    We are using  MEM type BIO. similar to the openssl
> library ‘BIO_TYPE_MEM ‘ we have an internal type defined like ex:-
> ‘BIO_TYPE_XYZ_MEM’  and all other mem utilities are internally defined.
> 
> Like XYZ_mem_new/XYZ_mem_read … etc  these utilities are accessing the
> bio_st variable ‘*num’*.
> 
> please suggest set/get utilities to handle this scenario.

If I understand correctly you want to store an "int" value internally to
a custom BIO.

Custom BIOs can associate an arbitrary data structure with the BIO
object and store whatever they like in it using the BIO_get_data() and
BIO_set_data() functions.

For example:

typedef struct {
int num;
} XYZ_PRIVATE_DATA;

static int XYZ_mem_new(BIO *bio)
{
XYZ_PRIVATE_DATA *data = OPENSSL_zalloc(sizeof(*data));

if (data == NULL)
return 0;

/* Store whatever you like in num */
data->num = 5;
BIO_set_data(bio, data);
}

static int XYZ_mem_free(BIO *bio)
{
XYZ_PRIVATE_DATA *data = BIO_get_data(bio);

OPENSSL_free(data);
BIO_set_data(bio, NULL);
}

static int XYZ_mem_read(BIO *bio, char *out, int outl)
{
XYZ_PRIVATE_DATA *data = BIO_get_data(bio);

/* Do the read operation and use data->num as required */
}


Matt

> 
> 
> Regards,
> 
> Sunil
> 
> *From:*openssl-users  *On Behalf Of
> *openssl-users-requ...@openssl.org
> *Sent:* 20 November 2020 23:34
> *To:* openssl-users@openssl.org
> *Subject:* openssl-users Digest, Vol 72, Issue 19
> 
>  
> 
> 
> 
> NOTICE: This email was received from an EXTERNAL sender
> 
> 
> 
> 
> Send openssl-users mailing list submissions to
> openssl-users@openssl.org <mailto:openssl-users@openssl.org>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> openssl-users-requ...@openssl.org <mailto:openssl-users-requ...@openssl.org>
> 
> You can reach the person managing the list at
> openssl-users-ow...@openssl.org <mailto:openssl-users-ow...@openssl.org>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
> 
> 
> Today's Topics:
> 
> 1. set/get utilities are not available to access variable
> 'num' of structure bio_st (Narayana, Sunil Kumar)
> 2. Re: set/get utilities are not available to access variable
> 'num' of structure bio_st (Matt Caswell)
> 3. EC curve preferences (Skip Carter)
> 4. RE: EC curve preferences (Michael Wojcik)
> 
> 
> --
> 
> Message: 1
> Date: Fri, 20 Nov 2020 13:46:00 +
> From: "Narayana, Sunil Kumar"  <mailto:sanaray...@rbbn.com>>
> To: "openssl-users@openssl.org <mailto:openssl-users@openssl.org>"
> mailto:openssl-users@openssl.org>>
> Subject: set/get utilities are not available to access variable
> 'num' of structure bio_st
> Message-ID:
>  <mailto:sn6pr03mb4061a9ff473de74b064a1d8db0...@sn6pr03mb4061.namprd03.prod.outlook.com>>
> 
> Content-Type: text/plain; charset="utf-8"
> 
> Hi ,
> We are porting our Application from openssl 1.0.1 to openssl 3.0. In
> related to this activity we require to access the variable 'num' of
> structure bio_st.
> In older versions the variable was accessed to set and get value using
> pointer operator (bi->num ).
> Since this is not allowed in 3.0 we are looking for the Get/Set
> utilities similar to other member (BIO_set_flags/ BIO_get_flags)
> 
> Is this not supported in 3.0 ? If yes, Please guide the proper alternatives.
> 
> Regards,
> Sunil
> 
> 
> ---
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that
> is confidential and/or proprietary for the sole use of the intended
> recipient. Any review, disclosure, reliance or
> distribution by others or forwarding without express permission is
> strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all
> copies, including any attachments.
> ---
> -- next part --
> An HTML att

Re: set/get utilities are not available to access variable 'num' of structure bio_st

[Matt Caswell]

On 20/11/2020 13:46, Narayana, Sunil Kumar wrote:
> Hi ,
> 
>     We are porting our Application from  openssl 1.0.1 to
> openssl 3.0. In related to this activity we require to access the
> variable ‘*num*’ of structure *bio_st. *
> 
> In older versions the variable was accessed to set and get value using
> pointer operator (bi->num ).
> 
> Since this is not allowed in 3.0 we are looking for the Get/Set
> utilities similar to other member*(BIO_set_flags/ BIO_get_flags) *
> 
>  
> 
> Is this not supported in 3.0 ? If yes, Please guide the proper alternatives.

What kind of BIO are you using? Different BIOs may provide different
mechanisms to get hold of this value. For example a number of file
descriptor based BIOs provide BIO_get_fd().

Matt

Re: openssl s_client connection fails

[Matt Caswell]

On 18/11/2020 11:24, Patrice Guérin wrote:
> 3072988928:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
> handshake failure:../ssl/record/rec_layer_s3.c:1407:SSL alert number 40

This is a very generic "something went wrong" alert that is being
received from the server and could be due to any number of issues. Do
you have access to the server in question? If so there may be more clues
in the server logs that might explain it.

> Does anybody have an idea on what's going wrong ?

One thing that springs to mind that often goes wrong is SNI handling.
s_client changed between 1.1.0 and 1.1.1 to always provider SNI by
default. If the server requires SNI then it could explain this
behaviour. Your can add SNI in 1.1.0 by using the "-servername" command
line option followed by the name of the server in question, e.g.

$ openssl s_client -connect www.openssl.org -port 443 -servername
www.openssl.org

Matt

> 
> Thank you in advance.
> Kind regards
> Patrice.
> 

Re: Server application hangs on SS_read, even when client disconnects

[Matt Caswell]

On 17/11/2020 13:56, Michael Wojcik wrote:
>> From: Kyle Hamilton 
>> Sent: Tuesday, 17 November, 2020 02:37
>> On Fri, Nov 13, 2020 at 11:51 AM Michael Wojcik
>>  wrote:
>>>
 From: Brice André 
 Sent: Friday, 13 November, 2020 09:13
>>>
 "Does the server parent process close its copy of the conversation socket?"
 I checked in my code, but it seems that no. Is it needed?
>>>
>>> You'll want to do it, for a few reasons: ...
>>
>> There's another reason why you'll want to close your socket with
>> SSL_close(): SSL (and TLS) view a prematurely-closed stream as an
>> exceptional condition to be reported to the application. This is to
>> prevent truncation attacks against the data communication layer.
>> While your application may not need that level of protection, it helps
>> to keep the state of your application in lockstep with the state of
>> the TLS protocol.  If your application doesn't expect to send any more
>> data, SSL_close() sends another record across the TCP connection to
>> tell the remote side that it should not keep the descriptor open.
> 
> This is true, but not what we're talking about here. When the
> application is done with the conversation, it should use SSL_close
> to terminate the conversation.
> 
> Here, though, we're talking about the server parent process closing
> its descriptor for the socket after forking the child process. At that
> point the application is not done with the conversation, and calling
> SSL_close in the server would be a mistake.
> 
> Now, if the server is unable to start a child process (e.g. fork fails
> because the user's process limit has been reached), or if for whatever
> other reason it decides to terminate the conversation without further
> processing, SSL_close would be appropriate.

Just for clarity, there is no such function as SSL_close. I assume
SSL_shutdown is what people mean.

Matt

Re: test cases failed after enabling ktls

[Matt Caswell]

On 16/11/2020 07:56, rui zang wrote:
> Resend in plain text.
> ==
> 
> Greetings,
>  
> I am trying openssl+ktls on ubuntu 20.04.
> I have tried openssl-3.0.0-alpha8 from 
> https://www.openssl.org/source/openssl-3.0.0-alpha8.tar.gz 
> and also the current master branch from the github repo.
> The kernels I have tried are v5.9 and v5.9.8.
> On every combination, same group of test case could not pass.


Please can you open this as a github issue?

Thanks

Matt


>  
> Test Summary Report
> ---
> 70-test_key_share.t  (Wstat: 1536 Tests: 22 Failed: 6)
>   Failed tests:  1, 4, 6-7, 13-14
>   Non-zero exit status: 6
> 70-test_sslextension.t   (Wstat: 256 Tests: 8 Failed: 1)
>   Failed test:  8
>   Non-zero exit status: 1
> 70-test_sslrecords.t (Wstat: 768 Tests: 20 Failed: 3)
>   Failed tests:  18-20
>   Non-zero exit status: 3
> 70-test_sslsigalgs.t (Wstat: 1536 Tests: 26 Failed: 6)
>   Failed tests:  1, 6, 22-23, 25-26
>   Non-zero exit status: 6
> 70-test_sslsignature.t   (Wstat: 256 Tests: 4 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> 70-test_sslversions.t(Wstat: 512 Tests: 8 Failed: 2)
>   Failed tests:  5, 7
>   Non-zero exit status: 2
> 70-test_tls13cookie.t(Wstat: 512 Tests: 2 Failed: 2)
>   Failed tests:  1-2
>   Non-zero exit status: 2
> 70-test_tls13downgrade.t (Wstat: 256 Tests: 6 Failed: 1)
>   Failed test:  6
>   Non-zero exit status: 1
> 70-test_tls13kexmodes.t  (Wstat: 7424 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 29
>   Parse errors: Bad plan.  You planned 11 tests but ran 1.
> 70-test_tls13messages.t  (Wstat: 7424 Tests: 1 Failed: 0)
>   Non-zero exit status: 29
>   Parse errors: Bad plan.  You planned 17 tests but ran 1.
> 70-test_tls13psk.t   (Wstat: 7424 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 29
>   Parse errors: Bad plan.  You planned 5 tests but ran 1.
> 70-test_tlsextms.t   (Wstat: 256 Tests: 10 Failed: 1)
>   Failed test:  10
>   Non-zero exit status: 1
> Files=223, Tests=3571, 615 wallclock secs (11.00 usr  0.93 sys + 343.65 cusr 
> 84.69 csys = 440.27 CPU)
> Result: FAIL
> make[1]: *** [Makefile:3197: _tests] Error 1
> make[1]: Leaving directory '/home/ubuntu/openssl'
> make: *** [Makefile:3194: tests] Error 2
>  
> Complete `make test` output  (kernel v5.9.8 + openssl master) is copied here 
> https://cl1p.net/openssl_ktls_make_test_failure (due to the 100K limit of 
> this mailing list)
> I am sure that the kernel tls module is loaded correctly since 
> /proc/net/tls_stat is exposed correctly and I can see the counters increasing 
> while doing `make test`.
> So is this supposed to happen? What should I do to make ktls work?
>  
> Thanks,
> Rui Zang
> 

Re: RAND_bytes() thread safety

[Matt Caswell]

On 14/11/2020 11:00, Rahul Godbole wrote:
> Is OpenSSL function RAND_bytes () thread safe?

Short answer: Yes

Longer answer: Yes assuming that:
- you are using >= OpenSSL 1.1.0
or
- you are using OpenSSL 1.0.2 or below and you have set up the locking
callbacks

AND

- You have not compiled OpenSSL with "no-threads"

Matt

Re: ## Application accessing 'ex_kusage' ##

[Matt Caswell]

On 13/11/2020 19:10, Narayana, Sunil Kumar wrote:
> Hi ,
> 
>     We are porting our Application from  openssl 1.0.1 to
> openssl 3.0. in related to this activity we require to access the
> variable ‘*ex_kusage*’ pointed by *X509*
> 
> But there are no set utilities available to access this variable. Only
>  X509_get_key_usage Is available.
> 
>  
> 
> Our code for 1.0.1 is as below. Please suggest the right way to achieve
> this.

I'd like to ask why you feel you need to do this at all. It seems to me
like you are replicating libcrypto internal code in your own
application. This is code in libcrypto:

/* Handle (basic) key usage */
if ((usage = X509_get_ext_d2i(x, NID_key_usage, &i, NULL)) != NULL) {
x->ex_kusage = 0;
if (usage->length > 0) {
x->ex_kusage = usage->data[0];
if (usage->length > 1)
x->ex_kusage |= usage->data[1] << 8;
}
x->ex_flags |= EXFLAG_KUSAGE;
ASN1_BIT_STRING_free(usage);
/* Check for empty key usage according to RFC 5280 section
4.2.1.3 */
if (x->ex_kusage == 0) {
ERR_raise(ERR_LIB_X509, X509V3_R_EMPTY_KEY_USAGE);
x->ex_flags |= EXFLAG_INVALID;
}
} else if (i != -1) {
x->ex_flags |= EXFLAG_INVALID;
}

So it seems very similar to what you are trying to do, and I guess some
earlier version of this code was the original source of what is in your
application now.

The purpose of this code is to decode the key usage extension and cache
it in the internal `ex_flags` value. This code gets called in numerous
code paths whenever we need to query extension data - including if you
were to call X509_get_key_usage().

Your application seems to want to manage for itself when libcrypto does
this caching. It should not need to do so - it's entirely internal. My
guess is that, perhaps, in some older version of OpenSSL the caching
didn't happen when it was supposed to and you implemented this
workaround?? Or possibly the workaround is still needed due to a bug in
OpenSSL that still doesn't do the caching when needed? If so I'd like to
understand the circumstances behind that.

Matt

Re: CRYPTO_mem_leaks Error in openssl 1.1.1d

[Matt Caswell]

On 10/11/2020 13:37, shiva kumar wrote:
> Can you please provide me examples or links to refer it.

Google is your friend here.

https://valgrind.org/

The above site has a quick start guide which should help.

Matt


> 
> On Tue, 10 Nov 2020 at 7:04 PM, Matt Caswell  <mailto:m...@openssl.org>> wrote:
> 
> 
> 
> On 10/11/2020 13:25, shiva kumar wrote:
> > Any alternatives for this, if the compiled version doesn't enabled
> the flag?
> 
> valgrind?
> 
> 
>     Matt
> 
> >
> > On Tue, 10 Nov 2020 at 4:52 PM, Matt Caswell  <mailto:m...@openssl.org>
> > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote:
> >
> >
> >
> >     On 10/11/2020 09:19, shiva kumar wrote:
> >     > Hi, 
> >     > I'm trying to use the CRYPTO_mem_leaks  API in openssl
> 1.1.1d, but
> >     > during compilation I'm getting error as 
> >     > *Unsatisfied symbol "CRYPTO_mem_leaks" *
> >     >
> >     > I have Included the header 
> >     > #include 
> >     >
> >     > one doubt is it is defined under crypto.h
> >     > #ifndef OPENSSL_NO_CRYPTO_MDEBUG
> >     > CRYPTO_mem_leaks //  defined
> >     > #endif 
> >     >
> >     > in opensslconf.h is defined as  
> >     > #ifndef OPENSSL_NO_CRYPTO_MDEBUG
> >     > #define OPENSSL_NO_CRYPTO_MDEBUG
> >     > #endif 
> >     >
> >     > How to resolve the issue?
> >
> >     The CRYPTO_mem_leaks API is not available by default. You have to
> >     compile a version of OpenSSL that has it enabled using the
> >     "enable-crypto-mdebug" option to "Configure":
> >
> >   
>  
> https://github.com/openssl/openssl/blob/6e933b35492a4dc3370b9f49890646dadca82cd8/INSTALL#L327-L329
> >
> >     Matt
> >
> > --
> > *With Best Regards*
> > *Shivakumar S*
> 
> -- 
> *With Best Regards*
> *Shivakumar S*

Re: CRYPTO_mem_leaks Error in openssl 1.1.1d

[Matt Caswell]

On 10/11/2020 13:25, shiva kumar wrote:
> Any alternatives for this, if the compiled version doesn't enabled the flag?

valgrind?


Matt

> 
> On Tue, 10 Nov 2020 at 4:52 PM, Matt Caswell  <mailto:m...@openssl.org>> wrote:
> 
> 
> 
> On 10/11/2020 09:19, shiva kumar wrote:
> > Hi, 
> > I'm trying to use the CRYPTO_mem_leaks  API in openssl 1.1.1d, but
> > during compilation I'm getting error as 
> > *Unsatisfied symbol "CRYPTO_mem_leaks" *
> >
> > I have Included the header 
> > #include 
> >
> > one doubt is it is defined under crypto.h
> > #ifndef OPENSSL_NO_CRYPTO_MDEBUG
> > CRYPTO_mem_leaks //  defined
> > #endif 
> >
> > in opensslconf.h is defined as  
> > #ifndef OPENSSL_NO_CRYPTO_MDEBUG
> > #define OPENSSL_NO_CRYPTO_MDEBUG
> > #endif 
> >
> > How to resolve the issue?
> 
> The CRYPTO_mem_leaks API is not available by default. You have to
> compile a version of OpenSSL that has it enabled using the
> "enable-crypto-mdebug" option to "Configure":
> 
> 
> https://github.com/openssl/openssl/blob/6e933b35492a4dc3370b9f49890646dadca82cd8/INSTALL#L327-L329
> 
> Matt
> 
> -- 
> *With Best Regards*
> *Shivakumar S*

Re: CRYPTO_mem_leaks Error in openssl 1.1.1d

[Matt Caswell]

On 10/11/2020 09:19, shiva kumar wrote:
> Hi, 
> I'm trying to use the CRYPTO_mem_leaks  API in openssl 1.1.1d, but
> during compilation I'm getting error as 
> *Unsatisfied symbol "CRYPTO_mem_leaks" *
> 
> I have Included the header 
> #include 
> 
> one doubt is it is defined under crypto.h
> #ifndef OPENSSL_NO_CRYPTO_MDEBUG
> CRYPTO_mem_leaks //  defined
> #endif 
> 
> in opensslconf.h is defined as  
> #ifndef OPENSSL_NO_CRYPTO_MDEBUG
> #define OPENSSL_NO_CRYPTO_MDEBUG
> #endif 
> 
> How to resolve the issue?

The CRYPTO_mem_leaks API is not available by default. You have to
compile a version of OpenSSL that has it enabled using the
"enable-crypto-mdebug" option to "Configure":

https://github.com/openssl/openssl/blob/6e933b35492a4dc3370b9f49890646dadca82cd8/INSTALL#L327-L329

Matt

Re: Questions regarding OpenSSL 3.0 and corresponding FIPS Module

[Matt Caswell]

On 05/11/2020 16:54, Jason Schultz wrote:
> I read the most recent (10/20) update to the OpenSSL 3.0 release page here:
> 
> https://www.openssl.org/blog/blog/2020/10/20/OpenSSL3.0Alpha7/
> 
> As well as the release
> strategy: 
> https://wiki.openssl.org/index.php?title=OpenSSL_3.0_Release_Schedule&oldid=3099
> 
> I have not done anything with the Alpha releases so far, but I noticed
> the note "Basic functionality plus basic FIPS module".
> 
> Does this mean that there is a FIPS module available to test with in the
> alpha(and presumably beta) releases?

Yes.

> 
> If the answer to that question is "yes", I'm assuming that the
> validation of that FIPS Module can't/won't start until after the Final
> OpenSSL 3.0 release. The timeframe for that validation is TBD, as it
> always varies.

Also yes.

> 
> The Final 3.0 release is currently behind schedule as it was estimated
> "early Q4 2020". Any ideas on how much behind that release is?

That is still the latest "official" time, but clearly that cannot be
achieved now given that we were supposed to have a beta in September in
that timeline. We still have quite a bit of work to do to get to a beta
release (https://github.com/openssl/openssl/milestone/17). The best I
can offer is that the final release will be "sometime in the New Year".

Matt

Re: PRNG not available when multiple providers are configured?

[Matt Caswell]

Ah! I had completely forgotten about this option.

Matt

On 03/11/2020 21:34, Dr Paul Dale wrote:
> Adding:
> |    config_diagnostics = 1|
> At the same level as the openssl_conf line should produce more output.
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 4 Nov 2020, at 4:41 am, Thomas Dwyer III > <mailto:tom...@tomiii.com>> wrote:
>>
>> On Tue, Nov 3, 2020 at 7:13 AM Matt Caswell > <mailto:m...@openssl.org>> wrote:
>>
>>
>>
>> On 03/11/2020 00:55, Thomas Dwyer III wrote:
>> > I'm having trouble getting RAND_status() to return 1 when my
>> openssl.cnf
>> > has both the default provider and the fips provider configured
>> at the
>> > same time:
>> > 
>> >         openssl_conf = openssl_init
>> > 
>> >         [openssl_init]
>> >         providers = provider_sect
>> > 
>> >         [provider_sect]
>> >         default = default_sect
>> >         fips = fips_sect
>> > 
>> >         [default_sect]
>> >         activate = 1
>> > 
>> >         .include /conf/openssl/fips.cnf
>> > 
>> > If I remove either default or fips from [provider_sect] then
>> > RAND_status() returns 1. If I leave them both specified there,
>> > RAND_status() always returns 0. Is this the expected behavior or
>> am I
>> > doing something wrong? I understand that I must specify
>> properties when
>> > fetching algorithms in order to get deterministic behavior with
>> multiple
>> > providers loaded. Is there an analogous API for the PRNG that I'm
>> > overlooking?
>> > 
>> > Interestingly, setting activate=0 for either provider is not
>> sufficient
>> > to work around this issue.
>>
>> I tested this out and was able to replicate your behaviour.
>>
>> The reasons are a little complicated (see below) but the TL;DR summary
>> is that there is an error in your config file. The ".include" line
>> should specify a config file relative to OPENSSLDIR (or
>> OPENSSL_CONF_INCLUDE if it is set). It cannot be an absolute path, and
>> hence fips.cnf is not being found.
>>
>>
>>
>> This explanation does not match my observations. strace clearly shows
>> my fips.cnf getting opened and read when my openssl.cnf has an
>> absolute path. Likewise, strace shows stat64("fips.cnf", ...) failing
>> (and thus no subsequent open() call) when I use a relative path.
>> Furthermore, the documentation
>> at https://www.openssl.org/docs/manmaster/man5/config.html
>> <https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man5/config.html__;!!GqivPVa7Brio!INBlyBEyGaYipDhT7pzBHbqNWwT_X9g1JEID9D5HZmFB-cmNRMWGUEoRqaZMNvs$>
>>  says
>> this should be an absolute path.*
>> *
>>
>> That said, see below..
>>
>>
>>
>> I've seen this error a few times now so I'm thinking that we should
>> perhaps allow absolute paths. I'm not sure what the reason for
>> disallowing them was.
>>
>> The reason it works if you comment out the "default" line is because
>> that means the only provider left is the FIPS one. But the config line
>> for that is faulty and therefore activating it fails. Ultimately
>> we have
>> not succesfully activated any provider. When you call RAND_status() it
>> will attempt to fetch the RAND implementation and find that no
>> providers
>> have been activated. In this case we fallback and automatically
>> activate
>> the default provider. Hence you end up with RAND_status() still
>> working.
>>
>> If you comment out the "fips" line then it works because it doesn't
>> attempt to do anything with the fips provider, successfully activates
>> the default provider, and hence RAND_status() works as expected.
>>
>> If you have both lines in the config file then it first successfully
>> activates the default provider. It next attempts to activate the fips
>> provider and fails. The way the config code works is that if any
>> of the
>> configured providers fail to activate then it backs out and
>> deactivates
>> all of them.