On Wed, Dec 17, 2008 at 11:57:33AM -0500, Steve Marquess wrote:

> >Can you elaborate on what these "tweaks" may be? I'll certainly 
> >consider facilitating a site selected FIPS mode in Postfix, ...
> 
> I'd be thrilled if you could do that.  I tried to cover that topic in
> chapter five of the User Guide,
> http://www.openssl.org/docs/fips/UserGuide-1.2.pdf.  The unusual link
> step for static linking is the tricky part, the rest is basically making
> sure *all* crypto is done via the FIPS-capable OpenSSL and illegal
> crypto operations don't crash or embarrass your app.  Please give it a
> read and let me know if you have any questions.  I'll respond as soon as
> I can (am on-site with a client now).
> 
> >... if this is not disruptive to non-FIPS users.
> 
> We put a lot of effort into developing FIPS support that could be
> enabled at runtime or not for the same binary code, with the FIPS-isms
> invisible until enabled.  One build, runtime selectable behavior.

FYI, on page 35, Example 5.2b and the text below it are somewhat garbled,
at least in the MacOSX PDF viewer:

            OPENSSL(config(XXXX_conf)

            #ifdef OPENSSL_FIPS
            if (FIPS_mode())
            {
                fprintf(stderr,"*** IN FIPS MODE ***\n");
            }
            #endif

        Example 5.2b --- Indirect Invocation of FIPS_mode_set()

    The call to OPENSSL_config(XXXX_conf) will check the system default
    OpenSSL configuration file for a section XXXX_conf.  If section XXXX_conf
    is not found then the section defaults to openssl_conf.  The resulting
    section is checked for a alg_section specification naming a section that
    can contain an optional "fips_mode = yes" statement.

            ...

        Example 5.2c --- Sample openssl.conf File

    Note that OPENSSL_config() has no return code.  If a configuration
    error occurs it will write to STDERR and forcibly exit the
    application.  Applications that want finer control can call the
    underlying functions such as CONF_modules_load_file() directly.

- OPENSSL(config(...) instead of OPENSSL_config(...) in the example

- In the PDF view, the closing ")" of the OPENSSL_config(...) call
  is not visible. It is only visible when one uses copy/paste to
  yank the text.

- The 0.9.8i man page for OPENSSL_config, does not document the exit on
  on error behaviour. Rather it says:

       The OPENSSL_config() function is designed to be a very simple "call it
       and forget it" function. As a result its behaviour is somewhat lim-
       ited. It ignores all errors silently and it can only load from the
       standard configuration file location for example.

  Was the documentation wrong all along, or does FIPS force a change in
  the documented semantics of existing APIs?

- The same manpage has an error in its references section:

    SEE ALSO
       conf(5), CONF_load_modules_file(3), CONF_modules_free(3),CONF_mod-
       ules_free(3)

- There is no conf(5) manpage, only a config(5) manpage

- There is no CONF_load_modules_file(3), only a CONF_modules_load_file(3)

- The CONF_modules_load_file(3) manpage refers to a missing CONF_free(3)
  manpage.

- There is no explanation of where one gets a "static CONF *"
  handle to use with CONF_modules_load(3).

- It is not stated when one should call CONF_load_modules_file(), before
  or after "add_***_algorithms". I assume the answer is "before". What
  about SSL_load_error_strings(), does that come first? Theer is language
  about the "error queue" in the CONF_modules_load(3) docs, so perhaps
  the error strings are to be loaded first. Is this the same error queue?

- If one uses CRYPTO_set_mem_function() and/or friends, I assume these go
  first, because the CONFIG code will use CRYPTO_malloc()?

There is probably a need for a comprehensive application initialization
document that puts all this in one place.


        - Initialize memory functions

        - Initialize error strings (or is this engine dependent)?

        - Initialize application configuration and/or FIPS

        - Initialize algorithms

This likely will need to wait for Postfix 2.7 snapshots in the Spring of
'09, because 0.9.8j is not out yet to validate this approach, and the
documentation is rather incomplete...

The strategy for Postfix would likely be an optional load of an
administrator-specified XXXX_conf section (not performed if not explicitly
set in main.cf), via an administrator specified openssl.cnf file (default
system-wide openssl.cnf). This can enable FIPs mode provided fipscanister
is linked-in, which would be a build-time option. If the "exit on error"
language for OPENSSL_config() is correct, I can't use that, and have to
use CONF_modules_load_file(3) instead.

Does this sound about right?

-- 
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to