Re: svn commit: r1914365 - in /httpd/httpd/trunk: changes-entries/ssl-providers.txt docs/log-message-tags/next-number docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_p
On Wed, Dec 13, 2023 at 11:33:16AM +0100, Ingo Franzki wrote: > On 13.12.2023 10:55, Joe Orton wrote: > > On Wed, Dec 06, 2023 at 01:02:01PM +0100, Yann Ylavic wrote: > >> Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice > >> pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path. > >> Sorry for the noise. > > > > Yes it should remain compatible like that, though you prompted me to > > re-read that and it would break for a no-engine build: r1914622. > Good catch! > How would one compile without OpenSSL having the engine API ? > At least currently, any supported OpenSSL version still does have the Engine > API. If you configure OpenSSL with the "no-engine" flag, you get OPENSSL_NO_ENGINE #define'd in the OpenSSL headers, and the engine API is not available. Looks like a few more places which assume ->szCryptoDevice is always there, so there may be other build issues. We need a CI config for this. > > I am not sure but we might want to add a new directive (yay) which loads > > a named provider, or we could rely on users doing that in openssl.cnf > > since configuring providers may be non-trivial (e.g. [1]). > I would not try to load a named provider. While loading a named provider can > be done using the OpenSSL provider API, > it is not possible to supply configuration parameters to that provider after > loading it. > Most provider I know do need specific configuration settings, they won't work > without them, especially the PKCS#11 providers. > So we must rely on users doing that in openssl.cnf. That makes sense to me, thank you. > > Other thing a colleage mentioned was that we may want to expand the list > > of URI schemes accepted here from just pkcs11://. > Sure, the provider code in general should work for any kind of URIs, not only > 'pkcs11:'. > It would even work for the 'file:' URI, loading the keys/certs from PEM files > (like the non-provider/non-engine code is doing already). > Actually it would even work for file names without a scheme at all, since the > default scheme is 'file:' anyway. > So it could theoretically replace the non-provider/non-engine load key/cert > code (not that I would suggests to change that as of today). Yup. We would have to be careful to make the logic around loading the chain from the file would work exactly the same if a file:// URI was used. I'm not sure what the best approach is - try loading everything via a store and then fallback to the old way, or again add a new config option(s?) SSLBlahURI. Regards, Joe
Re: svn commit: r1914365 - in /httpd/httpd/trunk: changes-entries/ssl-providers.txt docs/log-message-tags/next-number docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_p
On 13.12.2023 10:55, Joe Orton wrote: > On Wed, Dec 06, 2023 at 01:02:01PM +0100, Yann Ylavic wrote: >> Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice >> pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path. >> Sorry for the noise. > > Yes it should remain compatible like that, though you prompted me to > re-read that and it would break for a no-engine build: r1914622. Good catch! How would one compile without OpenSSL having the engine API ? At least currently, any supported OpenSSL version still does have the Engine API. > > I am not sure but we might want to add a new directive (yay) which loads > a named provider, or we could rely on users doing that in openssl.cnf > since configuring providers may be non-trivial (e.g. [1]). I would not try to load a named provider. While loading a named provider can be done using the OpenSSL provider API, it is not possible to supply configuration parameters to that provider after loading it. Most provider I know do need specific configuration settings, they won't work without them, especially the PKCS#11 providers. So we must rely on users doing that in openssl.cnf. > > Other thing a colleage mentioned was that we may want to expand the list > of URI schemes accepted here from just pkcs11://. Sure, the provider code in general should work for any kind of URIs, not only 'pkcs11:'. It would even work for the 'file:' URI, loading the keys/certs from PEM files (like the non-provider/non-engine code is doing already). Actually it would even work for file names without a scheme at all, since the default scheme is 'file:' anyway. So it could theoretically replace the non-provider/non-engine load key/cert code (not that I would suggests to change that as of today). > > [1] > https://github.com/tpm2-software/tpm2-openssl/blob/master/docs/initialization.md#tpm-command-transmission-interface-tcti > -- Ingo Franzki eMail: ifran...@linux.ibm.com Tel: ++49 (0)7031-16-4648 Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen Geschäftsführung: David Faller Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/
Re: svn commit: r1914365 - in /httpd/httpd/trunk: changes-entries/ssl-providers.txt docs/log-message-tags/next-number docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_p
On Wed, Dec 06, 2023 at 01:02:01PM +0100, Yann Ylavic wrote: > Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice > pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path. > Sorry for the noise. Yes it should remain compatible like that, though you prompted me to re-read that and it would break for a no-engine build: r1914622. I am not sure but we might want to add a new directive (yay) which loads a named provider, or we could rely on users doing that in openssl.cnf since configuring providers may be non-trivial (e.g. [1]). Other thing a colleage mentioned was that we may want to expand the list of URI schemes accepted here from just pkcs11://. [1] https://github.com/tpm2-software/tpm2-openssl/blob/master/docs/initialization.md#tpm-command-transmission-interface-tcti
Re: svn commit: r1914365 - in /httpd/httpd/trunk: changes-entries/ssl-providers.txt docs/log-message-tags/next-number docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_p
On Wed, Dec 6, 2023 at 11:05 AM Yann Ylavic wrote:
>
> On Tue, Dec 5, 2023 at 4:26 PM wrote:
> >
> > Author: jorton
> > Date: Tue Dec 5 15:26:22 2023
> > New Revision: 1914365
> >
> > URL: http://svn.apache.org/viewvc?rev=1914365=rev
> > Log:
> > mod_ssl: Add support for loading keys from OpenSSL 3.x providers via
> > the STORE API. Separates compile-time support for the STORE API
> > (supported in 3.x) from support for the ENGINE API (deprecated in
> > 3.x).
> >
> > * modules/ssl/ssl_private.h: Define MODSSL_HAVE_OPENSSL_STORE for
> > OpenSSL 3.0+.
> >
> > * modules/ssl/ssl_engine_pphrase.c (modssl_load_store_uri,
> > modssl_load_keypair_store): New functions.
> > (modssl_load_keypair_engine): Renamed from modssl_load_keypair_engine.
> > (modssl_load_engine_keypair): Reimplement to use new STORE-based
> > functions if SSLCryptoDevice was not configured, or else old
> > ENGINE implementation.
> >
> > * modules/ssl/ssl_util.c (modssl_is_engine_id): Match pkcs11: URIs
> > also for the OpenSSL 3.x STORE API.
> >
> > * modules/ssl/ssl_engine_init.c (ssl_init_server_certs): Tweak log
> > message on error paths for the provider/STORE case.
> >
> > Signed-off-by: Ingo Franzki
> > Submitted by: Ingo Franzki
> > Github: closes #397, closes #398
> >
> []
> >
> > Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c
> > URL:
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c?rev=1914365=1914364=1914365=diff
> > ==
> > --- httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c (original)
> > +++ httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c Tue Dec 5 15:26:22
> > 2023
> []
> > +
> > +apr_status_t modssl_load_engine_keypair(server_rec *s, apr_pool_t *p,
> > +const char *vhostid,
> > +const char *certid, const char
> > *keyid,
> > +X509 **pubkey, EVP_PKEY **privkey)
> > +{
> > +#if MODSSL_HAVE_OPENSSL_STORE
> > +SSLModConfigRec *mc = myModConfig(s);
> > +
> > +if (!mc->szCryptoDevice)
> > +return modssl_load_keypair_store(s, p, vhostid, certid, keyid,
> > + pubkey, privkey);
> > +#endif
> > +#if MODSSL_HAVE_ENGINE_API
> > +return modssl_load_keypair_engine(s, p, vhostid, certid, keyid,
> > + pubkey, privkey);
> > #else
> > return APR_ENOTIMPL;
> > #endif
>
> Hm, it seems that with openssl-3+ we can handle/support pkcs#11 URIs
> only via the store API now.
> modssl_load_keypair_store() will fail/die if it can't find the
> cert/key in the STORE, but couldn't modssl_load_keypair_engine() find
> them if the OpenSSL configuration (and underlying lib, e.g. libp11)
> still uses the legacy engine API? The engine API is still available in
> openssl-3 and might still be used IIUC.
>
> So don't we need something like this:
>
> apr_status_t rv = APR_ENOTIMPL;
> #if MODSSL_HAVE_OPENSSL_STORE
> SSLModConfigRec *mc = myModConfig(s);
> if (!mc->szCryptoDevice)
> rv = modssl_load_keypair_store(s, p, vhostid, certid, keyid,
>pubkey, privkey);
> #endif
> #if MODSSL_HAVE_ENGINE_API
> if (rv == APR_ENOTIMPL)
> rv = modssl_load_keypair_engine(s, p, vhostid, certid, keyid,
> pubkey, privkey);
> #endif
> return rv;
>
> and somehow make modssl_load_keypair_store() return APR_ENOTIMPL when
> there is no store to get the cert/key from?
Oh, scratch that. Actually the engine API requires a "SSLCryptoDevice
pkcs11" too, so we wouldn't take the !mc->szCryptoDevice path.
Sorry for the noise.
Regards;
Yann.
Re: svn commit: r1914365 - in /httpd/httpd/trunk: changes-entries/ssl-providers.txt docs/log-message-tags/next-number docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_p
On Tue, Dec 5, 2023 at 4:26 PM wrote:
>
> Author: jorton
> Date: Tue Dec 5 15:26:22 2023
> New Revision: 1914365
>
> URL: http://svn.apache.org/viewvc?rev=1914365=rev
> Log:
> mod_ssl: Add support for loading keys from OpenSSL 3.x providers via
> the STORE API. Separates compile-time support for the STORE API
> (supported in 3.x) from support for the ENGINE API (deprecated in
> 3.x).
>
> * modules/ssl/ssl_private.h: Define MODSSL_HAVE_OPENSSL_STORE for
> OpenSSL 3.0+.
>
> * modules/ssl/ssl_engine_pphrase.c (modssl_load_store_uri,
> modssl_load_keypair_store): New functions.
> (modssl_load_keypair_engine): Renamed from modssl_load_keypair_engine.
> (modssl_load_engine_keypair): Reimplement to use new STORE-based
> functions if SSLCryptoDevice was not configured, or else old
> ENGINE implementation.
>
> * modules/ssl/ssl_util.c (modssl_is_engine_id): Match pkcs11: URIs
> also for the OpenSSL 3.x STORE API.
>
> * modules/ssl/ssl_engine_init.c (ssl_init_server_certs): Tweak log
> message on error paths for the provider/STORE case.
>
> Signed-off-by: Ingo Franzki
> Submitted by: Ingo Franzki
> Github: closes #397, closes #398
>
[]
>
> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c?rev=1914365=1914364=1914365=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c Tue Dec 5 15:26:22
> 2023
[]
> +
> +apr_status_t modssl_load_engine_keypair(server_rec *s, apr_pool_t *p,
> +const char *vhostid,
> +const char *certid, const char
> *keyid,
> +X509 **pubkey, EVP_PKEY **privkey)
> +{
> +#if MODSSL_HAVE_OPENSSL_STORE
> +SSLModConfigRec *mc = myModConfig(s);
> +
> +if (!mc->szCryptoDevice)
> +return modssl_load_keypair_store(s, p, vhostid, certid, keyid,
> + pubkey, privkey);
> +#endif
> +#if MODSSL_HAVE_ENGINE_API
> +return modssl_load_keypair_engine(s, p, vhostid, certid, keyid,
> + pubkey, privkey);
> #else
> return APR_ENOTIMPL;
> #endif
Hm, it seems that with openssl-3+ we can handle/support pkcs#11 URIs
only via the store API now.
modssl_load_keypair_store() will fail/die if it can't find the
cert/key in the STORE, but couldn't modssl_load_keypair_engine() find
them if the OpenSSL configuration (and underlying lib, e.g. libp11)
still uses the legacy engine API? The engine API is still available in
openssl-3 and might still be used IIUC.
So don't we need something like this:
apr_status_t rv = APR_ENOTIMPL;
#if MODSSL_HAVE_OPENSSL_STORE
SSLModConfigRec *mc = myModConfig(s);
if (!mc->szCryptoDevice)
rv = modssl_load_keypair_store(s, p, vhostid, certid, keyid,
pubkey, privkey);
#endif
#if MODSSL_HAVE_ENGINE_API
if (rv == APR_ENOTIMPL)
rv = modssl_load_keypair_engine(s, p, vhostid, certid, keyid,
pubkey, privkey);
#endif
return rv;
and somehow make modssl_load_keypair_store() return APR_ENOTIMPL when
there is no store to get the cert/key from?
Regards;
Yann.
