On Sat Aug 24 21:16:05 2013, beld...@gmail.com wrote:
> Greetings!
>
> We have found an inconsistent behaviour of the openssl engine command. The
> problem appeared in version 1.0.1d in case openssl is built with
> --enable-shared.
>
> 1. When the config file does not mention the gost engine, the command
> “openssl engine” does not mention gost among the loaded engines. If we
> invoke “openssl engine gost”, it provides the necessary information about
> the engine. Everything is ok.
>
> 2. If we provide the describing gost engine section in the config file
> =============
> openssl_conf = openssl_def
> [ openssl_def ]
> engines = engines_section
> [ engines_section ]
> gost = gost_section
> [ gost_section ]
> engine_id = gost
> default_algorithms = ALL
> ==============
> “openssl engine gost” reports an error:
> =============
> GOST engine already loaded
> 140403073971872:error:260B606D:engine routines:DYNAMIC_LOAD:init
> failed:eng_dyn.c:521:
> 140403073971872:error:2606A074:engine routines:ENGINE_by_id:no such
> engine:eng_list.c:417:id=gost
> ==============
>
> It seems understandable because the gost engine should be loaded processing
> the config file, and the provided command tries to load the engine twice,
> and the second load is prohibited.
>
> But the command “openssl engine” still does not mention the gost engine
> among the loaded engines. Such a behaviour seems to be a bug.
>
> 3. If we provide the “dynamic_path” directive AFTER the
> “default_algorithms” one,
> (dynamic_path = path_to_openssl_dir/lib/engines/libgost.so) then either
> “openssl engine gost” or “openssl engine” without extra parameters cause
> an error:
>
> ===============
> GOST engine already loaded
> Error configuring OpenSSL
> 140167406061216:error:260B606D:engine routines:DYNAMIC_LOAD:init
> failed:eng_dyn.c:521:
> 140167406061216:error:260BC066:engine routines:INT_ENGINE_CONFIGURE:engine
> configuration error:eng_cnf.c:204:section=gost_section, name=dynamic_path,
> value=/path/to/lib/engines/libgost.so
> 140167406061216:error:0E07606D:configuration file
> routines:MODULE_RUN:module initialization
> error:conf_mod.c:235:module=engines, value=engines_section, retcode=-1
> ================
> This result differs from the behaviour of the 1.01c version. In the 1.0.1c
> version the error did not occur.
>
> 4. If we provide the “dynamic_path” directive BEFORE the
> “default_algorithms” one,
> (dynamic_path = path_to_openssl_dir/lib/engines/libgost.so) then “openssl
> engine” without extra parameters enlist the gost engine as loaded and the
> either “openssl engine gost” provides the information about the gost engine.
>
> We suppose that this inconsistency can cause a more serious problems. For
> example, we know that apache 2.2 gets a segfault using the gost engine with
> openssl 1.0.1e (it did not happen with earlier versions), though we did not
> investigate it yet.
>
What is happening is related to how ENGINE works with dynamically loaded
engines in different contexts.
If you do ENGINE_by_id("foo") it will first look for an engine called "foo" in
the list of engines and if present return a reference to that.
If "foo" is not present in the list it will then attempt to load a shared
library engine for "foo". If it succeeds a reference is returned for the loaded
engine. The new engine is NOT added to the list. It's this "unlisted" case that
causes problems with the gost engine.
If a second attempt is made to load "foo" then the code in the gost engine
prevents this: its use of static variables means it isn't safe to load it more
than once. There is AFAICS currently no way to just return a reference to the
unlisted engine which was loaded before.
The behaviour in the config file reflects this. If you just specify the engine
id "gost" you get the dynamic load and unlisted engine behaviour. Then using
"gost" on the command line tries to load it twice and you get an error.
If you use "dynamic_path" the engine is loaded *and* added. Then subsequent
attempts to use that engine work because it isn't loaded again: you just get
the existing listed reference.
The behaviour makes sense but it is not ideal. AFAICS the only way to handle
this cleanly is to avoid the "unlisted" case and always add the engine to the
list. Perhaps a new flag could be added to cover this.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
