• 17/10/2003

mod_ssl: F.A.Q.

  • What are the functional differences between mod_ssl and Apache-SSL, from where it is originally derived?    [L]

    This neither can be answered in short (there were too many code changes) nor can be answered at all by the author (there would immediately be flame wars with no reasonable results at the end). But as you easily can guess from the 5% of remaining Apache-SSL code, a lot of differences exists, although user-visible backward compatibility exists for most things.

    When you really want a detailed comparison you have to read the entries in the large CHANGES file that is in the mod_ssl distribution. Usually this is much too hard-core. So I recommend you to either believe in the opinion and recommendations of other users (the simplest approach) or do a comparison yourself (the most reasonable approach). For the latter, grab distributions of mod_ssl (from http://www.modssl.org) and Apache-SSL (from http://www.apache-ssl.org), install both packages, read their documentation and try them out yourself. Then choose the one which pleases you most.

    A few final hints to help direct your comparison: quality of documentation (“can you easily find answers and are they sufficient?”), quality of source code (“is the source code reviewable so you can make sure there aren’t any trapdoors or inherent security risks because of bad programming style?”), easy and clean installation (“can the SSL functionality easily added to an Apache source tree without manual editing or patching?”), clean integration into Apache (“is the SSL functionality encapsulated and cleanly separated from the remaining Apache functionality?”), support for Dynamic Shared Object (DSO) facility (“can the SSL functionality built as a separate DSO for maximum flexibility?”), Win32 port (“is the SSL functionality available also under the Win32 platform?”), amount and quality of functionality (“is the provided SSL functionality and control possibilities sufficient for your situation?”), quality of problem tracing (“is it possible for you to easily trace down the problems via logfiles, etc?”), etc. pp.

    • What are the major differences between mod_ssl and the commercial alternatives like Raven or Stronghold?    [L]

      In the past (until September 20th, 2000) the major difference was the RSA license which one received (very cheaply in contrast to a direct licensing from RSA DSI) with the commercial Apache SSL products. On the other hand, one needed this license only in the US, of course. So for non-US citizens this point was useless. But now even for US citizens the situations changed because the RSA patent expired on September 20th, 2000 and RSA DSI also placed the RSA algorithm explicitly into the public domain.

      Second, there is the point that one has guaranteed support from the commercial vendors. On the other hand, if you monitored the Open Source quality of mod_ssl and the support activities found on modssl-users@modssl.org, you could ask yourself whether you are really convinced that you can get better support from a commercial vendor.

      Third, people often think they would receive perhaps at least a better technical SSL solution than mod_ssl from the commercial vendors. But this is not really true, because all commercial alternatives (Raven 1.4.x, Stronghold 3.x, RedHat SWS 2.x, etc.) are actually based on mod_ssl and OpenSSL. The reason for this common misunderstanding is mainly because some vendors make no attempt to make it reasonably clear that their product is actually mod_ssl based. So, do not think, just because the commercial alternatives are usually more expensive, that you are also receiving an alternative technical SSL solution. This is usually not the case. Actually the vendor versions of Apache, mod_ssl and OpenSSL often stay behind the latest free versions and perhaps this way still do not include important bug and security fixes. On the other hand, it sometimes occurs that a vendor version includes useful changes which are not available through the official freely available packages. But most vendors play fair and contribute back those changes to the free software world, of course.

      So, in short: There are lots of commercial versions of the popular Apache+mod_ssl+OpenSSL server combination available. Every user should decide carefully whether they really need to buy a commercial version or whether it would not be sufficient to directly use the free and official versions of the Apache, mod_ssl and OpenSSL packages.

    • How do I know which mod_ssl version is for which Apache version?    [L]

      That’s trivial: mod_ssl uses version strings of the syntax -, for instance 2.4.0-1.3.9. This directly indicates that it’s mod_ssl version 2.4.0 for Apache version 1.3.9. And this also means you only can apply this mod_ssl version to exactly this Apache version (unless you use the --force option to mod_ssl’s configure command ;-).

    • Is mod_ssl Year 2000 compliant?    [L]

      Yes, mod_ssl is Year 2000 compliant.

      Because first mod_ssl internally never stores years as two digits. Instead it always uses the ANSI C & POSIX numerical data type time_t type, which on almost all Unix platforms at the moment is a signed long (usually 32-bits) representing seconds since epoch of January 1st, 1970, 00:00 UTC. This signed value overflows in early January 2038 and not in the year 2000. Second, date and time presentations (for instance the variable “%{TIME_YEAR}”) are done with full year value instead of abbreviating to two digits.

      Additionally according to a Year 2000 statement from the Apache Group, the Apache webserver is Year 2000 compliant, too. But whether OpenSSL or the underlaying Operating System (either a Unix or Win32 platform) is Year 2000 compliant is a different question which cannot be answered here.

    • What about mod_ssl and the Wassenaar Arrangement?    [L]

      First, let us explain what Wassenaar and it’s Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies is: This is a international regime, established 1995, to control trade in conventional arms and dual-use goods and technology. It replaced the previous CoCom regime. 33 countries are signatories: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom and United States. For more details look at http://www.wassenaar.org/.

      In short: The aim of the Wassenaar Arrangement is to prevent the build up of military capabilities that threaten regional and international security and stability. The Wassenaar Arrangement controls the export of cryptography as a dual-use good, i.e., one that has both military and civilian applications. However, the Wassenaar Arrangement also provides an exemption from export controls for mass-market software and free software.

      In the current Wassenaar “List of Dual Use Goods and Technologies And Munitions”, under “GENERAL SOFTWARE NOTE” (GSN) it says “The Lists do not control “software” which is either: 1. […] 2. “in the public domain”.” And under “DEFINITIONS OF TERMS USED IN THESE LISTS” one can find the definition: ““In the public domain”: This means “technology” or “software” which has been made available without restrictions upon its further dissemination. N.B. Copyright restrictions do not remove “technology” or “software” from being “in the public domain”.

      So, both mod_ssl and OpenSSL are “in the public domain” for the purposes of the Wassenaar Agreement and its “List of Dual Use Goods and Technologies And Munitions List”.

      Additionally the Wassenaar Agreement itself has no direct consequence for exporting cryptography software. What is actually allowed or forbidden to be exported from the countries has still to be defined in the local laws of each country. And at least according to official press releases from the German BMWi (see here) and the Switzerland Bawi (see here) there will be no forthcoming export restriction for free cryptography software for their countries. Remember that mod_ssl is created in Germany and distributed from Switzerland.

      So, mod_ssl and OpenSSL are not affected by the Wassenaar Agreement.