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@xxxxxxxxx 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
