Bug with OpenSSL engine initialization in tls_engine_load_dynamic_generic

[David Woodhouse]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20160606/c80fff4e/attachment.bin>