Re: openssl-users Digest, Vol 108, Issue 25

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Tom,

Thank you for your response. We want to perform fipsinstall using some API (not on terminal), which I need to execute at runtime after my service has started, on a demand basis, based on certain conditions. Hope it is clear.

Regards,
Memo

On Wed, Nov 22, 2023 at 1:28 AM <openssl-users-request@xxxxxxxxxxx> wrote:
Send openssl-users mailing list submissions to
        openssl-users@xxxxxxxxxxx

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-request@xxxxxxxxxxx

You can reach the person managing the list at
        openssl-users-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Programmatic Execution of the "OpenSSL-fipsinstall"
      Command (Ladd, Watson)
   2. TLS connect failure with an engine (OpenSSL 3.0.8)
      (Manish Patidar)
   3. Re: Programmatic Execution of the "OpenSSL-fipsinstall"
      Command (Thomas Dwyer III)


----------------------------------------------------------------------

Message: 1
Date: Tue, 21 Nov 2023 14:48:21 +0000
From: "Ladd, Watson" <wladd@xxxxxxxxxx>
To: meera pulse <memopulse@xxxxxxxxx>, "openssl-users@xxxxxxxxxxx"
        <openssl-users@xxxxxxxxxxx>
Subject: Re: Programmatic Execution of the "OpenSSL-fipsinstall"
        Command
Message-ID: <749d27cda12a44209aa69c6fded607b5@xxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

Yes, we've done it via the moral equivalent of postinstall hooks in our packaging system. It works reasonably straightfowardly.


________________________________
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of meera pulse <memopulse@xxxxxxxxx>
Sent: Tuesday, November 21, 2023 2:05 AM
To: openssl-users@xxxxxxxxxxx
Subject: Programmatic Execution of the "OpenSSL-fipsinstall" Command

Hello,

I am currently working on a project that involves the use of the "OpenSSL-fipsinstall" command, and I'm exploring the possibility of running it programmatically. I would appreciate some guidance on the steps involved and whether this approach is feasible.

Has anyone successfully executed the "OpenSSL-fipsinstall" command programmatically?
What steps need to be taken to achieve programmatic execution of "OpenSSL-fipsinstall"?
Are there any potential challenges or considerations that I should be aware of?
I'm eager to hear from anyone with experience or insights into this matter. Your assistance will be invaluable in helping me navigate through this aspect of my project.

Thank you in advance for your time and expertise!


Thanks,
Memo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20231121/ec32da30/attachment-0001.htm>

------------------------------

Message: 2
Date: Tue, 21 Nov 2023 23:47:38 +0530
From: Manish Patidar <mann.patidar@xxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: TLS connect failure with an engine (OpenSSL 3.0.8)
Message-ID:
        <CAN6ajHJ8dnj12Gdc8pKTECh=g3dkgUw3jn+EXSoPgVNN5ApgJA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Hi

I am using OpenSSL 3.0.8 with an engine .
We are using an engine for AES GCM encryption/decryption.
While TLS connection, connection is failing during change cipher state.

int tls1_change_cipher_state(SSL *s, int which) {
   if (EVP_CIPHER_get0_provider(c) != NULL
            && !*tls_provider_set_tls_params*(s, *dd*, c, m)) {
        /* SSLfatal already called */
        goto err;
    }
}
int tls_provider_set_tls_params(SSL *s, EVP_CIPHER_CTX **ctx*,
                                const EVP_CIPHER *ciph,
                                const EVP_MD *md) {
    if (!*EVP_CIPHER_CTX_set_params*(*ctx*, params)) {
        SSLfatal(s, SSL_AD_INTERNAL_ERROR, ERR_R_INTERNAL_ERROR);
        return 0;
    }
}

int EVP_CIPHER_CTX_set_params(EVP_CIPHER_CTX **ctx*, const OSSL_PARAM
params[])
{
    if (ctx->cipher != NULL && ctx->*cipher*->*set_ctx_params* != NULL) {
        ctx->iv_len = -1;
        return ctx->cipher->set_ctx_params(ctx->algctx, params);
    }
    *return 0;*
}
I think there is some issue here, as ctx->cipher is created from the
engine, *set_ctx_param* is not set in the ctx->cipher.
This check is leading to a drop in the connection.

If we bypass this check , the TLS connection is passing.
Is there something missing here, please let me know how to avoid this issue.

Regards
Manish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20231121/6f752570/attachment-0001.htm>

------------------------------

Message: 3
Date: Tue, 21 Nov 2023 11:56:43 -0800
From: Thomas Dwyer III <thomas.dwyer@xxxxxxxxxx>
To: openssl-users@xxxxxxxxxxx
Subject: Re: Programmatic Execution of the "OpenSSL-fipsinstall"
        Command
Message-ID: <36fc5eb9-728a-45a9-a0cb-749700aea3ad@xxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

When you say programmatically, do you mean executing literally the
"openssl fipsinstall" command with suitable arguments, or do you mean
running an equivalent replacement program? We do the latter, in a
slightly different way than the OpenSSL documentation provides. We
cross-compile OpenSSL on x86_64 for an embedded 32-bit ARM platform so
it's not possible for us to execute fipsinstall as part of our build
process (and non-compliant anyway since coping fipsmodule.cnf to other
systems is not allowed). Also, flash space constraints prohibit us from
including the large openssl binary in our images. And then there's the
chicken-egg situation with shipping a static configuration file that
".include"s a nonexistent fipsmodule.cnf.

Our solution was to ship a static configuration file that contains:

 ??? [fips_sect]
 ??? .include /path/to/fipsmodule.cnf

where fipsmodule.cnf (initially empty) resides in a smaller writable
location of flash separate from where most other things live. On first
boot we detect that fipsmodule.cnf is empty and we run a very small
standalone fipsinstall replacement that loads the FIPS provider, runs
the self-tests, and generates the same contents as "openssl fipsinstall"
but without the [fips_sect] header. This solves the problem of using
libcrypto with a syntactically incorrect configuration (i.e. where
[provider_sect] in the static openssl.cnf references [fips_sect] which
doesn't exist yet). Finally, we let the administrator toggle FIPS on/off
by storing a persistent flag that gets read by a constructor that we
added to libcrypto:

 ??? void __attribute__ ((constructor)) fipsmode(void)
 ??? {
 ??????? int mode = {fetch value of persistent flag}
 ??????? EVP_default_properties_enable_fips(NULL, mode);
 ??? }

Note that a forced reboot is required when toggling this flag since the
change won't apply to any instances of libcrypto already loaded by
running processes.

We can get away with this because we don't use OpenSSL's FIPS
certificate--we send our implementation through CMVP and get our own
certificate. That's probably cost-prohibitive for smaller organizations.


Tom.III


On 11/21/23 02:05, meera pulse wrote:
>
> Hello,
>
> I am currently working on a project that involves the use of the
> "OpenSSL-fipsinstall" command, and I'm exploring the possibility of
> running it programmatically. I would appreciate some guidance on the
> steps involved and whether this approach is feasible.
>
> Has anyone successfully executed the "OpenSSL-fipsinstall" command
> programmatically?
>
> What steps need to be taken to achieve programmatic execution of
> "OpenSSL-fipsinstall"?
>
> Are there any potential challenges or considerations that I should be
> aware of?
>
> I'm eager to hear from anyone with experience or insights into this
> matter. Your assistance will be invaluable in helping me navigate
> through this aspect of my project.
>
> Thank you in advance for your time and expertise!
>
> Thanks,
>
> Memo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20231121/fa8bc3ec/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
openssl-users@xxxxxxxxxxx
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 108, Issue 25
**********************************************

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux