Ok, let us start with the smooth transition to the mod_ssl 2.2 series. This
version started as mod_ssl 2.1.9 last week, but after I decided to do the
smooth transition, it evolved into 2.2.0. So, don't expect as much changes as
between 2.0.x and 2.1.0, of course. Actually you can expect an upgrade similar
to what would happen when it's called 2.1.9. The features for the 2.2 series
are already prepared but will be introduced from time to time with 2.2.x,
partly even as SSL_EXPERIMENTAL code.
This version introduces two of them: per-URL renegotiation of SSL parameters
to make the webserver SSL configuration more flexible (SSLCipherSuite,
SSLVerifyClient and SSLVerifyDepth can now be used in per-directory context,
too), and a new SSLRandomSeed directive which allows you to explicitly seed
the PRNG with entropy from an internal source, from an external file or even
from an external program. That's already a lot of new stuff for playing and
dumping core, so push it out now ;-) No, I was just kidding, the unstable
things are all wrapped with SSL_EXPERIMENTAL, of course.
Ben: Please have a look at my ssl_engine_kernel.c for the renegotiation
stuff. I think you can borrow some ideas there. At least the
SSL_set_state() is needed AFAIK to make your renegotiation stuff in
Apache-SSL really working. Additionally read the two big fat comments
there about the sub-requests of Apache. I think Apache-SSL should take
them into account, too.
Greetings,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
Changes with mod_ssl 2.2.0 (21-Jan-1999 to 27-Jan-1999)
*) Commit the long-prepared and long-awaited feature of
per-directory SSL configuration parameters.
The background is this: SSL parameters like the Cipher Suite or the
certificate chain verification parameters up to now could only be
configured on a per-(virtual)server basis and this way apply to all URLs
under https://this-virtual-server/. The drawback is obvious: You've to
find a common denominator for the whole website which isn't usually
possible. For instance just because you need client authentication
(``SSLVerifyClient require'') for https://this-virtual-server/foo/bar/,
this shouldn't mean you have to force client authentication for the
whole server. Same for ciphers: Just because a subarea needs to enforce
a stronger cipher (e.g. no export, no null cipher, etc.) shouldn't mean
that the whole website can only be visited with those requirements. So
the idea is to enforce those (usually stronger) requirements on a
per-directory basis.
The problem is: It's a chicken and egg situation. To decide which
parameters should be enforced in the SSL handshake mod_ssl has first to
find out the requested directory. For this the HTTP request has to be
read. But for this the SSL handshake first has to be performed. Bingo!
The nifty solution known from Netscape Commerce servers now is: We
simply do the standard SSL handshake, then we read the HTTP response,
then we perhaps reconfigure the parameters and enforce a second SSL
handshake (this is called "SSL renegotiation") with it. And only when
this handshake is also successful, the HTTP response is send.
How is this configured? You just put additional SSLVerifyClient,
SSLVerifyDepth and/or SSLCipherSuite directives in <Directory> or
<Location> containers or even .htaccess files. When Apache reaches those
directories, those directives reconfigure the SSL parameters and the SSL
renegotation is automatically enforced by mod_ssl. The only drawback is
that although an optimization is done to reduce unnecessary
renegotiations (when the parameters were not actually changed), you
usually increase the overhead for a request because a SSL renegotiation
is expensive. So, use the per-directory reconfiguration feature
economically.
Under SSL_EXPERIMENTAL additionally the directives SSLCACertificatePath
and SSLCACertificateFile can be used in per-directory context for
reconfiguration. But it's tagged experimental because SSLeay/OpenSSL
still lacks real support for this. So an ugly kludge has to be done to
support these two directives, too.
*) Give out more information on "Certificate Chain too long" error message.
*) Moved SSLeay/OpenSSL specific stuff to the new source files
ssl_util_ssl.[ch]. !! ATTENTION: NOW SSLeay 0.9.0 or OpenSSL IS NEEDED
!! Because the new internal structures need at least SSL_get_ex_data()
and SSL_set_ex_data() and those are not supported in SSLeay 0.8.x. So
we removed all remaining support for SSLeay 0.8.0. OTOH that's no
problem, because SSLeay 0.8.x is known to be unstable, so it's
reasonable to remove support for it also for other reasons.
*) Added a second SSL context variable which holds (with a delay) a pointer
back to the request_rec structure in Apache. This is needed to reach
the per-directory configuration parameters.
*) Updated the User Manual for mod_ssl 2.2
*) Added SSL_EXPERIMENTAL rule to Configuration.tmpl which
can be used to enable (APACI: ``--enable-rule=SSL_EXPERIMENTAL'')
experimental code inside mod_ssl. Code is declared experimental unless
it is proofed to be stable by the users.
*) Replaced the GNU Bison generated ssl_expr_parse.[ch] files with variants
generated by BSD Yacc. This way we have more portable source because BSD
Yacc doesn't used alloca() and other tricks. This especially should
solve the problems under HP/UX.
*) Updated INSTALL file for recent changes and fixed a few typos there.
*) Add a SSL_SDBM rule to Apache's Configuration.tmpl which can be used
(APACI: ``--enable-rule=SSL_SDBM'') to force mod_ssl to built with the
built-in SDBM instead of the custom defined (DBM_LIB) or vendor supplied
DBM library. This is especially useful when the vendor DBM library is
buggy or restricts the data size too dramatically (BTW, Berkeley-DB/1.x,
Berkely-DB/2.x and GDBM based DBM libraries are ok, because they allow
unlimited data size).
*) Enlarge the SDBM pag/dir blocksize from 1KB/4KB to 8KB/32KB to make sure
SDBM really can deal with SSL sessions containing long certificate
chains. !! ATTENTION: THIS MEANS THAT YOU'VE TO ONCE REMOVE THE FILE YOU
CONFIGURED WITH SSLSessioCache WHEN SDBM WAS USED AND YOU UPGRADE TO
THIS OR A LATER mod_ssl VERSION, BECAUSE THE INTERNAL LAYOUT CHANGED. SO
THE FILE HAS TO BE RECREATED WITH THE NEW LAYOUT !!
*) Make the DBM based session cache more robust by using additional error
situations. This should fix some observed core dumps on Linux boxes
where the vendor DBM library returned strange values.
*) Fixed configuration handling for global directives: Now the correct
memory pools are used and after the first configuration round the global
configuration structure is locked.
*) Added a new `SSLRandomSeed' directive for explicit seeding the Pseudo
Random Number Generator (PRNG) of the SSL library on server startup
and/or connection establishment time. The intent is that this way the
PRNG is better initialized and this way the security of the generated
SSL protocol ingredients are more secure (because less predictable). For
maximum flexibility you can use three seed sources: an internal source,
an external file or an an external program. And you can specify one or
more such sources, of course. For instance under a FreeBSD box you can
now use the following:
SSLRandomSeed startup builtin
SSLRandomSeed startup exec:bin/truerand 16
SSLRandomSeed startup file:/dev/random 512
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/random 512
SSLRandomSeed connect file:/dev/urandom 512
This would at server startup-time seed the PRNG first with a few bytes
from the internal source, plus 16 bytes read from stdout of the
`truerand' utility (which is based on the AT&T truerand library and can
be found in the mod_ssl distribution under pkg.contrib/), plus up to 512
bytes from the /dev/random device (it usually only returns a maximum
number of bits of randomness currently contained in the device entropy
pool) plus 512 bytes from the /dev/urandom device (which usually returns
as many bytes as requested, but of low random-quality). Additionally
before any new SSL connection is established the PRNG is again seed from
the internal source plus up to 512 bytes from /dev/random and plus 512
bytes from /dev/urandom. This should give an adequate seed for the PRNG
used for generating the SSL protocol ingredients.
*) Removed some unneccessary defines for `index' and `rindex'
in etc/patch/config.h which caused problems under AIX.
*) Changed a misleading sentence about RSAref in INSTALL
*) Overtake the idea of Apache-SSL 1.30 to log SSL errors also directly
after SSL_read/SSL_write. This way those error messages should no longer
be missed.
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
