                       _             _ 
   _ __ ___   ___   __| |    ___ ___| |  
  | '_ ` _ \ / _ \ / _` |   / __/ __| |  
  | | | | | | (_) | (_| |   \__ \__ \ |  mod_ssl - Apache Interface to SSLeay  
  |_| |_| |_|\___/ \__,_|___|___/___/_|  http://www.engelschall.com/sw/mod_ssl/
                       |_____|         
  _____________________________________________________________________________


  NEWS
  ----

  This file summarizes *major* changes to the mod_ssl package, i.e.
  between each *revision* (2.x -> 2.(x+1)).  Take this logfile
  for detailed information about user related or visible changes.

  Major changes between mod_ssl 2.0 and 2.1

  INTENT: The intent of mod_ssl 2.1 is to both kick out nasty relicts of
          Apache-SSL while adding new functionality which was missing to the
          Apache-SSL users for a long time.  In the 2.1.x releases the mod_ssl
          package will be mainly enhanced.

   [...]

   *) Replaced the parallel-process-based Global Session Cache with
      a new approach allowing to use DBM files or Shared Memory (SHM)
      segments. For this the `SSLSessioCache' directive was added.

   *) Overhauled pass phrase handling: now correctly handles the
      automatic terminal detachment, server restarts and additionally provides
      a plug-in feature for batch control.

      The problem in Apache-SSL was mainly that Apache detaches from the
      terminal before the SSLeay pass phrase dialog pops up). First I got rid
      of the ugly and unsuccessful filedescriptor hacks in Apache-SSL because
      they do not work under all platforms as expected.  Second I re-ordered
      the control flow to allow the following processing:

      Now at the 1st round of the Apache API init cycle the servers are
      scanned for certificate and key files and the first one which uses an
      encrypted key forces the pass phrase dialog to pop up. This dialog is
      either an interactive builtin terminal dialog (`SSLPassPhraseDialog
      builtin' - which is similar to SSLeay default dialog) or can be driven
      in batch by a filtering program which is run once and has to provide the
      pass phrase on stdout (`SSLPassPhraseDialog /path/to/program').  After
      this the pass phrase is _temporarily_ stored in memory for use later in
      the 2nd round of the Apache API init cycle. Now additionally this pass
      phrase can be kept in memory (`SSLPassPhraseCaching on') for forthcoming
      server restarts (`kill -HUP') or is explicitly wiped out from memory
      (`SSLPassPhraseCaching off' - for the paranoid users).

   *) A new directive was added to configure the loadable CA certificates.
   
      Now mod_ssl provides the configuration directive SSLCACertificateReqFile
      which can be used to configure a different (from SSLCACertificateFile)
      set of CA certifcates for the SSLv3 feature used by clients to load CA
      certifcates from the server for speeding up server authentication (the
      so-called `SSLv3 write certificate request A'). This way one can
      explicitly configure which CA certificates can be loaded by the clients.

   *) Replaced `SSLEnable'/`SSLDisable' with `SSLEngine on|off' and
      change the default from on/SSLEnable to off/SSLDisable.

      First it was a little bit ugly in Apache-SSL that two separate
      directives existed for turning on and off the SSL engine while all other
      Apache modules use a single directive with a flag for such situations.
      So mod_ssl now uses the single directive `SSLEngine'. Second it was
      nasty in Apache-SSL the default was an enabled SSL engine, because SSL
      is an additional feature and it's horrible to have to add an SSLDisable
      to every non-SSL-aware virtual host (especially for ISPs which run
      thousend of them). So in mod_ssl the default now is `SSLEngine off' and
      one only have to use `SSLEngine on' inside the SSL-aware virtual hosts.

   *) A new dedicated SSL log file handling with log levels was added.

      Now mod_ssl provides a real dedicated SSL log file controlled by log
      levels and the additional feature that messages logged at the `error'
      level are automatically duplicated to the general Apache error log file.
      And occuring system and SSLeay error messages are automatically appended
      to all mod_ssl messages.  Additionally typical appended SSLeay low-level
      messages are annotated with high-level hints.  This way one can trace
      the SSL processing in more granular and clear detail. To control the
      amount of verbosity a new directive SSLLogLevel was added. Finally the
      directive name was changes from `SSLLogFile' to `SSLLog' to conform both
      to the other log directives of Apache and because it's no longer
      restricted to simple files (it now also can log to a program via a
      reliable pipe).
        
  ____________________________________________________________________________

  Major changes between Apache-SSL 1.x and mod_ssl 2.0

  INTENT: The intent of mod_ssl 2.0 is to provide an Apache SSL solution
          based on Apache-SSL 1.x which is very clean and well integrated.
          In the 2.0.x releases the mod_ssl package was mainly stabilized.

   *) mod_ssl provides a complete documentation
   
      A new mod_ssl.html was created which documents all configuration
      directives, environment variables, etc. while Apache-SSL still has no
      such documentation although it exists for over three years now.
      Additionally mod_ssl.html provides answers to often occuring frequently
      asked questions in the Apache/SSL/SSLeay area.  For instance it gives
      detailed hints about how to setup a CA, how to create real a server
      certificate, etc. Because these are the typical hurdles every user
      stumbles over.

   *) mod_ssl provides clean and documented source code
   
      The intent is that only this way the user is able to re-view it for
      backdoors, security holes, etc.  This is considered important for
      security-related software.  It was absolutely incomprehensible to the
      author how Apache-SSL could exist for over three years while both the
      source code and the source patches were provided in an undocumented and
      partly unreadable format. For the mod_ssl package the source codes
      follows the Apache coding style, is logically ordered to follow the API
      phases and even the patches to the Apache source tree are annotated with
      descriptions to give the user a chance to re-view and understand them.

   *) mod_ssl can be easily applied to the Apache source tree
   
      Because mod_ssl provides an automated process for this task while
      Apache-SSL forces the user to fiddle with the `patch' and `cp' tools
      theirself. Just because security is not for amateurs haven't mean that
      user friendliness is not important. So it's a must to assist the user in
      applying the SSL-stuff to vanilla Apache sources.

   *) mod_ssl fixes a lot of bugs and inconsistencies in Apache-SSL
   
      For Apache experts here are a few impressions: Apache-SSL wrote directly
      to `stderr' instead of the Apache error logfile; it messed up it's error
      messages with the SSLeay error messages, it directly patched the
      SERVER_BASEVERSION define instead of using the Apache 1.3 conforming
      ap_add_version_component() function; it used the unsafe sprintf()
      function instead of the robust ap_snprintf(); it incorrectly spawned and
      killed the gcache auxiliary program and it totally failed to pass the
      ``gcc -Wall -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes
      -Wmissing-declarations -Wnested-externs -Winline'' test (while Apache
      passes it) because of unclean code.

      Additionally Apache-SSL it didn't provide a way to easily apply it to
      the Apache source tree (semi-manual editing and patching was required);
      it didn't seamlessly integrate into the new Apache 1.3 Autoconf-style
      Interface (APACI) under configuration time; it didn't automatically
      recognize the difference between an installed SSLeay and an
      out-of-the-source-only SSLeay; it didn't provide integration into the
      APACI installation process (`make install'); it used numbers 0 to 2
      instead of reasonable names for the argument of SSLVerifyClient just
      because internally an `enum' was used and for the provided `%{version}c'
      construct of CustomLog it used the results "2", "3" under SSLeay 0.8
      while under SSLeay 0.9 the results were "SSL2", "SSL3", etc. pp.

