Bug with OpenSSL engine initialization in tls_engine_load_dynamic_generic

Jouni Malinen j at w1.fi
Sun Jun 5 07:06:52 PDT 2016


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.. 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..

> I'm not sure what's the best way to fix this issue but you'll find a
> patch proposal in the end that iterates over the available engines
> instead of using ENGINE_by_id to avoid the engine autoload.

I'm not sure this would be generic enough if there is need to change
parameters and wpa_supplicant allows the configuration parameters like
pkcs11_module_path to be changed at runtime.. That might require an
additional ENGINE_ctrl_cmd_string() call at some point.. And I'm not
sure whether that would even work in practice, i.e., whether the pkcs11
engine allows such a change after having been used for some operations.

Even for the case where nothing really changes in the configuration, I'm
not sure I see why there would be need to query anything for OpenSSL
either.. Wouldn't it be sufficient to track within wpa_supplicant
whether the specific engine has been loaded or not?

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.

-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list