On Wed, May 05, 1999, Ben Laurie wrote:
> > > [...]
> > > d) Apache-SSL supports DSOs.
> >
> > Are you sure, Ben? At least I still cannot image how you support DSO while
> > Apache-SSL still uses direct symbol references between the Apache core and the
> > apache_ssl module (the big "no-no" for DSO). Either you mean something
> > different by DSO ("DSO support" usually means an apache_ssl.so can be built
> > and used) or my knowledge of DSO lacks some details.
>
> I mean that any other DSO can be used.
Ahh, ok. Then you speak about different types of DSO support for Apache-SSL.
Sure, there is no reason why other modules cannot be used as a DSO with
Apache-SSL. But usually the question is whether Apache-SSL itself can use the
DSO mechanism, of course.
> Since SSL can be disabled easily,
> it isn't a big deal that Apache-SSL itself can't be a DSO. And nor can
> mod_ssl in any useful sense of the word: you still have to patch Apache
> in the first place.
Hmmm.. the actual point is flexibility, Ben: For instance ISPs usually have
very different customer requirements. So they want to make a generic Apache
installation and run various custom Apache instances out of this single and
shared installation. When you have to always built mod_ssl+OpenSSL into the
httpd, it's bloated up for all customers while usually only 10% of them really
need the SSL functionality. For these situations the DSO facility was mainly
added to Apache. Because it allows you to assemble the functionality under
startup-time and not under built-time. That's very important when you've to
administrate lots of webservers.
Sure, I know that you can argue with some copy-on-write and other Unix
VM-system related issues when it comes to final runtime differences. But keep
in mind that the stuff is usually not only a technical issue. Customers want
their server as clean and small as possible and don't accept any unused large
overheads (even when you can technically argue that it's not a problem).
> > And the
> > reason for the possibility to spawn an external program is to allow people to
> > plug-in smart card applications or similar stuff without patching mod_ssl. It
> > doesn't increase security, of course. But that's not the goal of this
> > feature...
>
> It reduces security, which is why I don't support it.
Why does the possibility reduces security, Ben? It's same same as this: Just
because you've the possibility to remove the pass phrase from a private key
doesn't mean that security is reduced in general. It's only reduced when you
use this possibility. Same for the use of an external program. It's neither
more nor less secure then removing the pass phrase. But it's a different
approach which can help people in some situations. Sorry, I still cannot
accept the argument that this possibility itself makes anything less secure
than not having this possibility. As long as you don't use it, nothing
changes. And when you use it all you've to remember is that nothing will
change from the security point of view - only the technical approach changes.
> > > h) replacing gcache with DBM seems a backward step to me.
> >
> > You've still not said "why"? Because of the DBM key/value size restrictions?
> > Or because of the lower access? The size restriction is actually no real
> > problem, because it only means some very large certificate chains cannot be
> > cached. The lower access might be an argument, but keep in mind that for
> > mod_ssl 2.3.0 I've already written a shared memory based alternative which
> > beats both gcache and DBM caches in performance, of course. BTW, the reason
> > why I've replaced gcache with a DBM approach was not performance: It was
> > stability.
>
> Because DBM is a single-user facility, so it is highly inefficient.
You speak about the mutex issue? Hmm... in practice I was never able to find
the processes blocking very long. So when it comes to efficieny I would count
more the disk I/O overhead. But even for this a good DBM library needs only 2
seeks plus a small read I/O burst. But sure, it's slower than gcache, no
doubt.
> Although gcache was a bit troublesome at first, there is no stability
> problem I know of, and I use it for many production systems.
Fine. Yes, and gcache can be very interesting when it also comes to some
tricks (for instance running the cache on a different server). But in general
I wanted to avoid spawned processes and DBM was the only possibility until
shared memory exists. For mod_ssl 2.3.0 I'll go the shared memory way now I've
implemented the MM library. This way I can provide at least again maximum
efficieny and performance.
> > > Also, I notice that parts of that FAQ were written by me, yet strangely
> > > there is no credit [...]
> >
> > Correct. The reason is that you already get proper credit on more prominent
> > locations (even directly on the website welcome page and the README in
> > the distribution, etc.) for the _whole_ mod_ssl distribution (where the FAQ is
> > only a small part). But when you insist on some extra credit in the
> > FAQ-Chapter you can get it, of course. But please stop such indirect attacks,
> > Ben. Thanks.
>
> Umm. What kind of attack would you call your FAQ?
Harmless attacks IMHO, because I've already adjusted it according to your
explicit requests six months ago and so assumed it's now finally ok for you.
But I'm tired of these blames, so I've now completely removed any Apache-SSL
related comparisons from the FAQ and now there are only generic comparison
hints left (which I'll _not_ remove, of course). Additionally I've now extra
rewritten the two FAQ entries from scratch to avoid any more blames for them,
too. Check out the new FAQ under http://www.modssl.org/docs/2.3/ssl_faq.html
and feel free to stop blaming. But let me know when I've to kick out some
more stuff. Thanks, Ben.
Greetings,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
