httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: SSL support
Date Sun, 04 Feb 2001 19:00:41 GMT
"Ralf S. Engelschall" wrote:
> In article <> you wrote:
> > [...]
> > Right, I'm not touching that area at all, all I'm doing is handling the
> > details of how you interface SSL to filters.
> > [...]
> Ahh, ok. Thanks for clarifying this point, Ben.
> > [...]
> > I am not aware of any functionality EAPI provides that isn't already
> > available in Apache 2.0.
> > [...]
> For instance: structure contexts for attaching arbitrary information;

I don't know what you mean by this (unless you mean the kind of contexts
that are already spattered around throughout the Apache API's

> totally loosely coupled hooks without any symbol references between
> provider/server and user/client; etc... Think about this especially in
> the context of DSOs and what Apache 2.0 currently supports here.

We already have these, and done type-safely (which ISTR you claimed was
impossible - one of my original complaints about EAPI).

> > [...]
> >> Because I
> >> _definitely_ don't want to rewrite an SSL/TLS module from scratch again
> >> mainly because of political reasons - mod_ssl is already full-featured
> >> and consists of clean code.
> >
> > That's in the eye of the beholder. _I_ think mod_ssl is spaghetti.
> That might be correct. It sometimes have a too long control flow through
> functions -- but that can be changed easily. More important for Apache
> 2.0 should be that IMHO the mod_ssl code base is already rock solid and
> provides all necessary SSL/TLS glue functionality to OpenSSL. Because
> having to reimplement all this stuff from scratch would be a waste of
> time for 2.0 IMHO.

So is Apache-SSL. And it isn't spaghetti.

> > [...]
> > I'm not sure that "backward-compatible" is a design aim, particularly
> > not if "backward-compatible" means "compatible with mod_ssl".
> mod_ssl is 98% compatible with all other SSL modules, including
> Apache-SSL. Kicking out this already existing compatibility would be
> unreasonable for the acceptance of Apache 2.0, I think. So, whatever
> we do for Apache 2.0 should be mostly backward-compatible, except for
> cases where a new architecture or cleanups prevent us from keeping
> compatibility. But just saying "compatible with mod_ssl is not
> important" would be very unreasonable for us, although it is clear that
> you personally have to disagree here, Ben... ;)

There are two aspects to that, one being compatibity at the
configuration level - which may be appropriate, or may not, depending on
how much else has changed at the configuration level. The other being
compatibility at the code level, which is definitely not appropriate.

> > [...]
> > No. What you are saying is that we can have any SSL implementation we
> > like so long as it is mod_ssl.
> No, I say: we can have any SSL implementation we like so long as it
> provides mostly the same functionality as mod_ssl. Hey, that I would
> appreciate that we base the implementation on the mod_ssl code base is
> an _OFFER_ to the group, because I think only this way we can provide
> full-featured SSL/TLS support for Apache 2.0 in a reasonable short time
> (less than 0.5 year of development). So I'm a little bit puzzled where
> the problem is and that no one beside you give a pro/con statement here.
> > That's unacceptable. What we agreed was
> > that there would be an abstraction such that _third-party_ modules to
> > provide things like caching, certificate verification, etc., could be
> > added, but that _none_ of the functionality would be ported from either
> > Apache-SSL or mod_ssl.
> I remember that we agreed to use an abstraction layer. But that we
> don't port over old code was not said or at least not agreed by me. I
> certainly don't want to reimplement SSL/TLS support for Apache 2.0 from
> scratch, because such a job I've already done in 1998 for Apache 1.3.

And I did it in '95 - so what? And, indeed, that's what you based your
implementation on.

> I just have to make sure mod_ssl's functionality survives for Apache
> 2.0. Whether we use my mod_ssl code for this or not is not really
> important to me. So, if _YOU_ reimplement the old functionality from
> scratch I'll be certainly happy. But if it means that people expect that
> _I_ reimplement the old functionality for 2.0 just because political
> reasons deny the use of my old mod_ssl code base, _I_ personally
> certainly will not do this.

Nobody is asking you to reimplement anything.

>                                - - -
> So, in short, to make it clear: I think mod_ssl's SSL/TLS functionality
> (not code base!) has to survive for Apache 2.0! Because I was already
> unhappy in 1998 with the SSL/TLS functionality Apache-SSL provided (and
> started mod_ssl) and so I don't want to have the same problem again with
> Apache 2.0's mod_tls. People, stand up and speak about your opinion.

It isn't as clearcut as that. For example, mod_ssl's scheme for
admission control based on certificate contents is, IIRC, a home-brewed
language, whereas Apache-SSL's is based on Keynote. I happen to think
that Keynote is superior, but that is beside the point - the admission
control clearly must be pluggable in order to support both approaches.
Whether one or both of the available admission control modules becomes
part of Apache, or whether they remain external, is another question
altogether. I find it difficult to believe that we can get a clean
pluggable interface more easily by mangling a non-pluggable one than by
implementing from scratch. A similar argument applies to caching.

> So, dependent whether the group agrees on my point (that mod_ssl's
> functionality has to survive for 2.0), there are two situations I can
> imagine:
> 1. The group agrees.
>    This means I don't have to provide mod_ssl externally any longer and
>    so (to make our development easier) offer the whole mod_ssl code
>    base under the ASF license to the group. Whether it is then taken
>    over completely or only partly or not at all is then not important
>    any longer to me. If parts are taken over I also offer to help with
>    this integration job, of course. But if code is reimplemented it
>    has to be done by someone else. Because my time is more limited than
>    in the last years, so I certainly will not spend time on political
>    reimplementations. I then just want that people don't blame me, if
>    mod_ssl functionality is lost. It's then the group's decision if the
>    gifted mod_ssl code base is forced to dead.
> 2. The group disagrees.
>    This means, as long as the Apache 2.0 SSL/TLS solution is still not
>    acceptable for the large mod_ssl user community I've to continue
>    maintaining mod_ssl externally for Apache 2.0. I really would hate
>    this, because it would cost me even more time than (1).
> That's the only possibilities from the mod_ssl point of view.
> So, if (1) is the case, I still offer to commit mod_ssl 2.8.x to
> httpd-2.0/src/modules/ssl/ under the ASF license as a code base for the
> new httpd-2.0/src/modules/tls/ stuff. Once mod_tls is sophisticated
> enough (either by porting over from mod_ssl or by reimplementing),
> httpd-2.0/src/modules/ssl/ can be deleted at all. I would appreciate
> that you do the same with your Apache-SSL code base, too. So, why is
> this offer not appreciated by the group? We do not loose anything...

I think the problem is that we aren't at the point where either mod_ssl
or Apache-SSL are useful for hacking code out of - we first need to deal
with the question of APIs. Of course, the code for either is easily
available to anyone who wants to refer to it already, without cluttering
the source tree with it.

The other point is that I'm just as anxious as you are to no longer have
to support Apache-SSL, and I do not believe I am going to get there by
porting mod_ssl.




"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

View raw message