Bug with OpenSSL engine initialization in tls_engine_load_dynamic_generic

[Michael Schaller]

David explains correctly what happens. This started happening for us
on Debian testing with the release of the libengine-pkcs11-openssl
package version 0.2.1-2 in March 2016 and it took us a while to
analyze the issue. The package had changed the libpkcs11.so location
from /usr/lib/ssl/engines/libpkcs11.so to
/usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/libpkcs11.so. Since
this move the autoload of the pkcs11 engine on the ENGINE_by_id call
works and we get a pkcs11 engine initialized for the use of p11-kit
instead of the expected initialization for the specified opencryptoki
module. We initialize the pkcs11 engine and module path via D-Bus via
the SetPKCS11EngineAndModulePath method.

David, is the general recommendation to switch over to p11-kit?

On Mon, Jun 6, 2016 at 10:26 AM David Woodhouse <dwmw2 at infradead.org> wrote:
>
> On Sun, 2016-06-05 at 17:06 +0300, Jouni Malinen wrote:
> > On Mon, May 30, 2016 at 07:19:40PM +0200, Michael Schaller wrote:
> > > The first ENGINE_by_id call (line 730) in
> > > tls_engine_load_dynamic_generic is used to check if a certain OpenSSL
> > > engine is already loaded:
> > > https://w1.fi/cgit/hostap/tree/src/crypto/tls_openssl.c#n730
> > >
> > > This ENGINE_by_id call has a side effect though that it automatically
> > > loads that engine with the default options if the shared object of
> > > that engine can be found by openssl. This means that if the autoload
> > > succeeds then this check will always be true and hence this engine
> > > can't ever be loaded with the specific options for WPA supplicant as
> > > specified in the configuration.
> >
> > Could you please provide some more details on a case where this happens
> > and what those specific options in the configuration would be?
> >
> > I tried to test this myself, but for some reason, did not see OpenSSL
> > being able to load any engine automatically..
>
> Historically, the PKCS#11 engine required you to jump through a lot of
> hoops to load and use it. We fixed this fairly recently. I suspect it's
> only Fedora where you can expect it to work out of the box with the
> distribution packages so far, but it will reach other distributions in
> time.
>
> You used to have to load the engine manually, and you used to have to
> specify the PKCS#11 module manually.
>
> Now you don't. It's named 'libpkcs11.so' in the OpenSSL engines
> directory so it's loaded automatically with ENGINE_by_id(), and it
> loads p11-kit-proxy.so as its module by default — so the system-
> configured PKCS#11 tokens for the process in question are automatically
> available.
>
> So it really should be as simple as loading the module, then using a
> PKCS#11 URI (as specified in RFC7512) to reference the key and/or
> certificate.
>
> In commit 96955192 I already fixed the code to automatically load the
> PKCS#11 engine when the string given for the cert or key starts with
> 'pkcs11:' and thus looks like a standard PKCS#11 URI.
>
> >  Anyway, looking at the
> > related configuration parameters, other than the specific directory of
> > the engine file, the only thing that seems to impact the engine loading
> > operations seems to be the module patch for pkcs11. And even that could
> > potentially be set with ENGINE_ctrl_cmd_string() after the
> > ENGINE_by_id() call..
>
> All of that is legacy crap. You shouldn't need it these days.
>
> > I'm not very familiar with the existing OpenSSL engine cases, so it is
> > somewhat difficult to speculate on the best way of addressing this,
> > though.
>
> The most interesting use case is when you just put a PKCS#11 URI into
> the 'private_key' or 'client_cert' fields instead of a file name, and
> it Just Works™.
>
> Import a cert into gnome-keyring or something like that (using
> seahorse). Run 'p11tool --list-all pkcs11:token=Gnome2%20Key%20Storage'
> and note the URL of the key and/or cert you want to use. Put them into
> the configuration file. That's it¹.
>
> You can also use certs/keys from your NSS softoken database, if you ask
> nicely.
>
> There are other engines, which are mostly uninteresting because people
> should be offering PKCS#11 modules for their hardware instead of
> OpenSSL-specific engines. And there are historical and/or badly-
> configured or badly-installed instances of ENGINE_pkcs11. Which aren't
> worth pandering to if they've been broken since 2002 either,
>
> (Although if they've only been broken since last year when I changed a
> bunch of stuff here, then fixing them *might* make sense).
>
> --
> David Woodhouse                            Open Source Technology Centre
> David.Woodhouse at intel.com                              Intel Corporation
>
>
> ¹ By using gnome-keyring as the example, I've neatly side-stepped the
>   question of providing the PIN, which is unfortunately still *different*
>   in the wpa_supplicant config file depending on whether you're using
>   GnuTLS or OpenSSL, IIRC. That ought to be uniform, but isn't.