Re: Establishing connection errors

2021-11-05 Thread Jason Schultz
To clarify, I will probably just use the API you suggested to make it more 
simple. Was distracted by my obvious oversight.



From: openssl-users  on behalf of Jason 
Schultz 
Sent: Friday, November 5, 2021 1:59 PM
To: Tomas Mraz ; openssl-users@openssl.org 

Subject: Re: Establishing connection errors

Sorry, accidentally skipped that part, which was sort of important. I think I 
can use the same fix because the part I skipped is the problem:

X509  *cert;
cert = PEM_read_X509(fp, NULL, 0, NULL);
status = X509_STORE_add_cert(trusted_store,cert);

So, I need to this sequence:

X509 *empty_X509;
empty_X509 = X509_new_ex(non_fips_libctx, NULL);
mycert = PEM_read_X509(fp, _X509, 0, NULL);

To set things up correct, with the appropriate library context.

My apologies, thanks for pointing out my small brain.

This could lead to some tricky changes as currently I set up the trust store 
before I know if the user wants FIPS or not. I may just set up two stores, or I 
need to change the order of how I do things.

Thanks,

Jason



From: Tomas Mraz 
Sent: Friday, November 5, 2021 1:52 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: Establishing connection errors

On Fri, 2021-11-05 at 13:48 +, Jason Schultz wrote:
> For setting up the trusted store, when the application starts, it
> calls:
>
> ssl_trusted_certs = X509_STORE_new()
>
> ...and then reads all of the certificates in /etc/ssl/certs/ calling

> X509_STORE_add_cert(trusted_store,cert);
>
> ..for each one.

How do you read the certs? They need to be loaded with the appropriate
libctx.

Or you can use for example X509_STORE_load_file_ex() function to load a
file directly with an libctx.

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




Re: Establishing connection errors

2021-11-05 Thread Jason Schultz
Sorry, accidentally skipped that part, which was sort of important. I think I 
can use the same fix because the part I skipped is the problem:

X509  *cert;
cert = PEM_read_X509(fp, NULL, 0, NULL);
status = X509_STORE_add_cert(trusted_store,cert);

So, I need to this sequence:

X509 *empty_X509;
empty_X509 = X509_new_ex(non_fips_libctx, NULL);
mycert = PEM_read_X509(fp, _X509, 0, NULL);

To set things up correct, with the appropriate library context.

My apologies, thanks for pointing out my small brain.

This could lead to some tricky changes as currently I set up the trust store 
before I know if the user wants FIPS or not. I may just set up two stores, or I 
need to change the order of how I do things.

Thanks,

Jason



From: Tomas Mraz 
Sent: Friday, November 5, 2021 1:52 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: Establishing connection errors

On Fri, 2021-11-05 at 13:48 +, Jason Schultz wrote:
> For setting up the trusted store, when the application starts, it
> calls:
>
> ssl_trusted_certs = X509_STORE_new()
>
> ...and then reads all of the certificates in /etc/ssl/certs/ calling

> X509_STORE_add_cert(trusted_store,cert);
>
> ..for each one.

How do you read the certs? They need to be loaded with the appropriate
libctx.

Or you can use for example X509_STORE_load_file_ex() function to load a
file directly with an libctx.

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




Re: Establishing connection errors

2021-11-05 Thread Tomas Mraz
On Fri, 2021-11-05 at 13:48 +, Jason Schultz wrote:
> For setting up the trusted store, when the application starts, it
> calls:
> 
> ssl_trusted_certs = X509_STORE_new() 
> 
> ...and then reads all of the certificates in /etc/ssl/certs/ calling 

> X509_STORE_add_cert(trusted_store,cert);
> 
> ..for each one.

How do you read the certs? They need to be loaded with the appropriate
libctx.

Or you can use for example X509_STORE_load_file_ex() function to load a
file directly with an libctx.

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




Re: Establishing connection errors

2021-11-05 Thread Jason Schultz
Setup of the non_fips_libctx (after help from this list a week or two ago):

non_fips_libctx = OSSL_LIB_CTX_new();
defp = OSSL_PROVIDER_load(non_fips_libctx, "default");

I also call

OSSL_PROVIDER_available(non_fips_libctx, "default")

...to verify this worked. I only load the default provider in the non-FIPS 
non-default library context.

In case you need this info, for the fips library context, I call:

OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf")

With the following relevant info in openssl-fips-cnf:

.include /usr/local/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect

# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
fips = fips_sect
base = base_sect

# If no providers are activated explicitly, the default one is activated 
implicitly.
# See man 7 OSSL_PROVIDER-default for more details.
#
# If you add a section explicitly activating any other provider(s), you most
# probably need to explicitly activate the default provider, otherwise it
# becomes unavailable in openssl.  As a consequence applications depending on
# OpenSSL may not work correctly which could lead to significant system
# problems including inability to remotely access the system.
[default_sect]
# activate = 1

[base_sect]
activate = 1

And in fipsmodule.cnf:

[fips_sect]
activate = 1
conditional-errors = 1
security-checks = 1
module-mac = 
E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9

Also verifying this worked with the following:

OSSL_PROVIDER_available(fips_libctx, "base")
OSSL_PROVIDER_available(fips_libctx, "fips")


For setting up the trusted store, when the application starts, it calls:

ssl_trusted_certs = X509_STORE_new()

...and then reads all of the certificates in /etc/ssl/certs/ calling

X509_STORE_add_cert(trusted_store,cert);

..for each one.

Then, I make the following calls to set up intermediate certs in the trust 
store to be treated as trust-anchors:

param = X509_VERIFY_PARAM_new();
X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_PARTIAL_CHAIN);
X509_STORE_set1_param(ssl_trusted_certs, param);
X509_VERIFY_PARAM_free(param);

Then I set the store for verifying peer certs to this "global" store I created 
above:

status = SSL_CTX_set1_verify_cert_store(ctx,ssl_trusted_certs);

For the sake of completeness, I also call:

status = SSL_CTX_set1_chain_cert_store(ctx, ssl_trusted_certs);

...to ensure OpenSSL has access to the entire store for forming a certificate 
chain to present to the peer in a handshake. My application can act as a client 
and/or a server, and in this case, it's acting as both the client and the 
server, with the same SSL_CTX. Also, this code has always worked with OpenSSL 
1.1.1, which is why I was suspicious of either my library context/provider 
setup, or 3.0.

Let me know if you need more info.

Thanks,

Jason



From: Tomas Mraz 
Sent: Friday, November 5, 2021 1:19 PM
To: Jason Schultz ; openssl-users@openssl.org 

Subject: Re: Establishing connection errors

On Fri, 2021-11-05 at 13:04 +, Jason Schultz wrote:
> I know I've been raising a lot of issues this week, because of
> varying reasons, but I've hit another one that seems like either an
> OpenSSL problem, or something new/different I need to do with OpenSSL
> 3.0 in connection establishment.
>
> To recap, I'm using two non-default library contexts, one for FIPS,
> one for non-FIPS. There is an open issue in github regarding the call
> to SSL_CTX_build_cert_chain(), but since the purpose of that call is
> to have the server not include the root certificate when sending the
> chain, I have left that out of my code for now, in order to continue
> testing. It shouldn't affect what I'm trying to do.
>
> As far as connection set up, based on whether or not the user wants
> FIPS (not using FIPS for this test), I call:
>
> ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());
>
> ...to set up my SSL_CTX. My understanding is that all SSL objects,
> etc., created based on that SSL_CTX will use the appropriate library
> context/providers. So beyond the providers and library context setup
> and using SSL_CTX_new_ex(), I haven't changed any code to establish
> TLS connections. I've tried to establish connections using both RSA
> and ECDSA certificates/keys, self-signed, or a server cert that's
> part of a chain. I'm just establishing a connection to myself, not
> between two systems, just to try to get something working. I'll post
> all of the handshake messages at the end of this message, but here
> are the error messages I get when the client side receives the server
> certificate (in this case it's a self signed RSA cer

Re: Establishing connection errors

2021-11-05 Thread Tomas Mraz
On Fri, 2021-11-05 at 13:04 +, Jason Schultz wrote:
> I know I've been raising a lot of issues this week, because of
> varying reasons, but I've hit another one that seems like either an
> OpenSSL problem, or something new/different I need to do with OpenSSL
> 3.0 in connection establishment.
> 
> To recap, I'm using two non-default library contexts, one for FIPS,
> one for non-FIPS. There is an open issue in github regarding the call
> to SSL_CTX_build_cert_chain(), but since the purpose of that call is
> to have the server not include the root certificate when sending the
> chain, I have left that out of my code for now, in order to continue
> testing. It shouldn't affect what I'm trying to do.
> 
> As far as connection set up, based on whether or not the user wants
> FIPS (not using FIPS for this test), I call:
> 
> ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); 
> 
> ...to set up my SSL_CTX. My understanding is that all SSL objects,
> etc., created based on that SSL_CTX will use the appropriate library
> context/providers. So beyond the providers and library context setup
> and using SSL_CTX_new_ex(), I haven't changed any code to establish
> TLS connections. I've tried to establish connections using both RSA
> and ECDSA certificates/keys, self-signed, or a server cert that's
> part of a chain. I'm just establishing a connection to myself, not
> between two systems, just to try to get something working. I'll post
> all of the handshake messages at the end of this message, but here
> are the error messages I get when the client side receives the server
> certificate (in this case it's a self signed RSA certificate):

How do you set up the non_fips_libctx and how do you set up any
certificate trust store within the SSL_CTX?

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




Establishing connection errors

2021-11-05 Thread Jason Schultz
I know I've been raising a lot of issues this week, because of varying reasons, 
but I've hit another one that seems like either an OpenSSL problem, or 
something new/different I need to do with OpenSSL 3.0 in connection 
establishment.

To recap, I'm using two non-default library contexts, one for FIPS, one for 
non-FIPS. There is an open issue in github regarding the call to 
SSL_CTX_build_cert_chain(), but since the purpose of that call is to have the 
server not include the root certificate when sending the chain, I have left 
that out of my code for now, in order to continue testing. It shouldn't affect 
what I'm trying to do.

As far as connection set up, based on whether or not the user wants FIPS (not 
using FIPS for this test), I call:

ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method());

...to set up my SSL_CTX. My understanding is that all SSL objects, etc., 
created based on that SSL_CTX will use the appropriate library 
context/providers. So beyond the providers and library context setup and using 
SSL_CTX_new_ex(), I haven't changed any code to establish TLS connections. I've 
tried to establish connections using both RSA and ECDSA certificates/keys, 
self-signed, or a server cert that's part of a chain. I'm just establishing a 
connection to myself, not between two systems, just to try to get something 
working. I'll post all of the handshake messages at the end of this message, 
but here are the error messages I get when the client side receives the server 
certificate (in this case it's a self signed RSA certificate):

211105074132.795:info_cb:SSL_connect error in SSLv3/TLS read server certificate
211105074132.795:SSL_process_hs: SSL_ERROR_SSL on SSL_do_handshake
   Socket: 20  SSL flag: 2  HS role: 0
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0308010C:digital envelope routines::unsupported
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0372:digital envelope routines::decode error
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0372:digital envelope routines::decode error
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0372:digital envelope routines::decode error
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0372:digital envelope routines::decode error
211105074132.795:SSL_process_hs: SSL_ERROR_SSL ERR_get_error error string:
   error:0580006C:x509 certificate routines::unable to get certs public key

Some of those errors are pretty generic, but when searching the 3.0 source for 
the "unable to get certs public key" error, some familiar functions pop up, for 
example, here:

int X509_self_signed(X509 *cert, int verify_signature)
{
EVP_PKEY *pkey;

if ((pkey = X509_get0_pubkey(cert)) == NULL) { /* handles cert == NULL */
ERR_raise(ERR_LIB_X509, X509_R_UNABLE_TO_GET_CERTS_PUBLIC_KEY);
return -1;
}
if (!ossl_x509v3_cache_extensions(cert))
return -1;
if ((cert->ex_flags & EXFLAG_SS) == 0)
return 0;
if (!verify_signature)
return 1;
return X509_verify(cert, pkey);
}

and here:

/* Copy any missing public key parameters up the chain towards pkey */
int X509_get_pubkey_parameters(EVP_PKEY *pkey, STACK_OF(X509) *chain)
{
EVP_PKEY *ktmp = NULL, *ktmp2;
int i, j;

if (pkey != NULL && !EVP_PKEY_missing_parameters(pkey))
return 1;

for (i = 0; i < sk_X509_num(chain); i++) {
ktmp = X509_get0_pubkey(sk_X509_value(chain, i));
if (ktmp == NULL) {
ERR_raise(ERR_LIB_X509, X509_R_UNABLE_TO_GET_CERTS_PUBLIC_KEY);
return 0;
}
if (!EVP_PKEY_missing_parameters(ktmp))
break;
ktmp = NULL;
}


>From issue #16966, we know the X509_get_pubkey() call can have issues with 
>library contexts. I don't know the internals of OpenSSL enough to know if this 
>is a similar issue.

I can open an Issue in github if Matt, Tomas, or others think it's appropriate.

Thanks,

Jason

PS: Here is the full handshake capture (there are a few logs from my 
application mixed in):

211105074132.786:info_cb:0x89c330 SSL_accept:before SSL initialization
211105074132.786:SSLEvent(4): Matching session table found for port/addr 
2110/10.61.152.77
211105074132.786:info_cb:SSL_accept error in before SSL initialization
211105074132.786:SSL_process_hs: SSL_ERROR_WANT_READ on SSL_do_handshake
Socket: 21  SSL flag: 1  HS role: 1
Socket should be put back on read list to be polled again
211105074132.786:AllocateTcpRecvBuffers(4):call InsertWaitObject() for socket 
20 returned: 0
211105074132.786:info_cb:0x8ae0b0 SSL_connect:before SSL initialization
211105074132.787:msg_cb:0x8ae0b0 >>> TLS 1.0  [length 0005]
211105074132.787:16 03 01 00 d8
211105074132.787:msg_cb:0x8ae0b0 >>> TLS 1.3 Handshake [length 00d8], 
ClientHello
211105074132.787:01 00 00 d4 03 03 56 75 bc