[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-ssl
Subject:    Feedback: 1.25
From:       "Ralf S. Engelschall" <rse () engelschall ! com>
Date:       1998-09-27 15:19:25
[Download RAW message or body]


I've currently studied the Apache-SSL 1.24->1.25 changes and want to give Ben
and the Apache-SSL users a little feedback:

o IMHO, the APACHE_SSL_EXPORT_CERTS define would be good to
  be a configuration-time rule (--enable-rule=APACHE_SSL_EXPORT_CERTS or Rule
  APACHE_SSL_EXPORT_CERTS=yes). Because it can be a noticeable performance
  penalty, so it seems reasonable to not enable it per default.  Because when
  the client certificate chain contains N certs for each HTTPS request now N
  additional cache lookups are done. At least when gcache is configured to use
  TCP sockets this can have a noticable effect.

o The new AddCertToEnv() function uses i2d_X509() + uuencoden()
  for exporting the X509 structure to a Base64 encoded buffer. Wasn't Mark
  Shutteworth's original suggestion that the SSL_CLIENT_CERT_CHAIN_x variables
  contain the certificates in PEM format, i.e. Base64 _including_ the begin
  and end delimiter lines? What's wrong with using PEM_write_bio_X509() which
  directly gives this format for a X509?  Because this the information can be
  easier fed into SSLeay or other libraries.

o There is a little inconsistency: Under APACHE_SSL_KEEP_CERTS the
  cert numbering start from 1, under !APACHE_SSL_KEEP_CERTS it starts from 0.
  It's seems to be ok in general (>=1), but at least the number 0 is missing
  under APACHE_SSL_KEEP_CERTS, i.e. the server cert, isn't it?  IMHO at least
  an additional AddCertToEnv(r->pool,e,"SSL_CLIENT_CERT_CHAIN_0",xs); is
  needed at around line 400 in apache_ssl.c.

o Apache-SSL 1.25 still doesn't pass the standard GCC compile test:
  OPTIM='-Wall -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes
         -Wmissing-declarations -Wnested-externs -Winline'
  while all other Apache 1.3 sources do. It's not hard to fix this
  and it would make the source cleaner.

o Was it a reasonable idea to perform this change?
  -SSLVerifyClient 0
  +SSLVerifyClient 3
  IMHO it's a mistake and Ben just forgot to remove it before rolling the
  distribution. A lot of people will be confused because 3 means at least a
  request is performed for the client cert.

o The SSL_BASE & Co configuration stuff has to be performed manually.
  Additionally variables like SSL_CFLAGS are used (for which additional
  Makefile.tmpl patches has to be done). IMHO it's better to follow what other
  modules (including mod_ssl) do: Use the Apache 1.3 configuration script
  stubs. This way Apache-SSL can auto-adjust paths for the difference between
  source-only and installed SSLeay _and_ can avoid the extra patching by just
  _extending_ CFLAGS instead of using own additional variables. Ben, you don't
  have to create such an advanced libssl.module which is used for mod_ssl (and
  which does RSAref support, etc.), but at least a minimalistic one can
  be a great advantage to Apache-SSL, too.

o In apache_ssl.c now there is:
  |   /* if we want to export cert chains we have to cache them, which is not
  |   currently done, so, for now, disable caching */
  |   #if CACHE_SESSIONS && APACHE_SSL_EXPORT_CERTS && 0
  |   # undef CACHE_SESSIONS
  |   #endif
  Because of the "&& 0" it's disabled, of course. But even without
  this is seems to be wrong. Shouldn't the logic lead to this:
  |   #if !CACHE_SESSIONS && APACHE_SSL_EXPORT_CERTS
  |   #define CACHE_SESSIONS
  |   #endif
  Because for the APACHE_SSL_EXPORT_CERTS the cache is needed, so it has to be
  turned on when APACHE_SSL_EXPORT_CERTS is active and it still isn't turned
  on. 

o I appreciate the final decision of Ben for Apache-SSL 1.25 to replace the
  unsecure sprintf's he used in the past with the more secure ap_psprintf &
  ap_snprintf & ap_cpystrn. It needed some time, but now it's finally done.
  Fine.

o Finally: The whole SSL_CLIENT_CERT and SSL_CLIENT_CERT_CHAIN_x stuff
  should be documented a little bit better than just 
  | SSL_CLIENT_CERT         <string>  Base64 encoding of client cert
  | SSL_CLIENT_CERT_CHAIN_n <string>  Base64 encoding of client cert chain
  At least people should be informed that SSL_CLIENT_CERT is the same as
  SSL_CLIENT_CERT_CHAIN_0.

So, I'm still not convinced that the SSL_CLIENT_CERT_CHAIN_x stuff is now done
the best way. Especially because of two reasons:

  1. The weighting between the additional and noticeable runtime 
     overhead and the rare situations where someone will use
     SSL_CLIENT_CERT_CHAIN_x still makes me not happy

  2. At least under my FreeBSD 2.2.6 box I still have the problem
     that the simple printenv CGI script hangs when such huge
     environment variables are created.

I'm still thinking about an alternative and my current state is this:

  1. The complete SSL_CLIENT_CERT_CHAIN_x generation the user should
     be able to trigger _under runtime_ via `SSLOptions +EnvCertChain'
     directives in .htaccess or similar things. This way the runtime overhead
     is Null and only when the user really needs this stuff it can be enabled.

  2. Passing such huge information via env variables should be avoided.
     IMHO it's better to pass a unique identifier (<= 80 chars) and then an
     interface should be provided through which a CGI script can retrieve the
     cert chain information via this identifier. My current idea is that the
     identifier is a unique URL to the same server and the CGI can retrieve
     the _whole_ cert chain through this URL in one step. 
     
     An alternative would be to use a DBM file where the CGI can lookup the
     whole cert chain information via the identifier. Because it's when the
     CGI needs SSL_CLIENT_CERT_CHAIN_x it always needs the _complete_ chain or
     the whole stuff is useless. And to retrieve N certs through N different
     env vars seems ugly to me. IMHO its better to have one source (a URL or
     DBM file plus identifier) where one can get the cert chain as a whole. 

It would be nice when users give us their opinions, too.
Ben and I can only provide good solutions when we know what our users 
actually want and _how_ they want it.

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

[prev in list] [next in list] [prev in thread] [next in thread]