Thanks guys this is great stuff. Very entertaining.
Cheers, g-
"Ralf S. Engelschall" wrote:
>
> 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]
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
