httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: SSL support
Date Sun, 04 Feb 2001 14:01:05 GMT
"Ralf S. Engelschall" wrote:
> 
> In article <3A7C6660.7CB42DF3@algroup.co.uk> Ben Laurie wrote:
> 
> > OK, I'm not going to wait around for someone else to take the lead any
> > more - so I've started work on mod_tls (name chosen to avoid confusion).
> > I intend to check stuff in as soon as I have it working even a little -
> > this is going to be a group activity :-)
> 
> Errr... we all agreed at ApacheCon that before we check-in any SSL/TLS
> code, we want to reach sonsensus on what underlaying SSL/TLS abstraction
> layer we want to use for such a module!

Right, I'm not touching that area at all, all I'm doing is handling the
details of how you interface SSL to filters.

I hope that this will stimulate people to start thinking about the
bigger picture.

> As a reminder, this was _YOUR_ suggestion at ApacheCon 2000-EU. My
> suggestion, if people remember, was that I just port mod_ssl to Apache
> 2.0 API, kickout any code which is no longer necessary because of APR,
> assign the whole copyright on _ALL_ mod_ssl code over to the ASF, commit
> the stuff to Apache 2.0 source tree and let us all together as a group
> work on enhancing/polishing the whole SSL/TLS stuff for 2.0.
> 
> For obvious personal reasons, my suggestion was not liked by you, so you
> convinced the group that we start from scratch with an abstraction layer
> API by a small mod_tls.[ch] which encapsulates the SSL/TLS related parts
> of the Apache 2.0 API and _later_ we just plug in existing code from
> Apache-SSL and mod_ssl which performs the SSL/TLS operations by just
> using this API and OpenSSL.
> 
> So I'm confused what your current approach actually is and what it means
> for us. But I really hope that before any _SSL/TLS CODE_ is comitted,
> there is first a _detailed_ architecture document written (a plain text
> mod_tls.txt with the essential points) where the whole abstraction API
> and its interaction with the Apache core code is described.

Ralf, I've seen you squash plans to add autoconf to OpenSSL twice by
insisting on this approach - and then doing nothing about it. If you
want a detailed document, by all means write it. That's not how I work,
so I'm afraid I'm not going to. And I'm not going to wait until one is
written either.

> I just don't want to see a similar situation for mod_ssl, as it
> happended with my EAPI one year ago for Apache 2.0: you comitted code
> without previous discussions and evaluations of existing code and as a
> result the existing code was forced to be dead, although it still could
> provide important functionalities but no longer any developer cares
> about it, because it is already forgotten by the group.

I am not aware of any functionality EAPI provides that isn't already
available in Apache 2.0. It is not the case that there was no previous
discussion - there was plenty of discussion that came to no conclusion.
If you remember, it was on the relative merits of EAPI and KEAPI.

> You can be sure that for mod_ssl (which is more important to our
> community than the unimportant EAPI stuff) I have to make sure that
> this does not happen again. What I certainly will not accept is that a
> 10% SSL/TLS solution is comitted and then people just say "Hey Ralf,
> now help on completing this because its a group effort". 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.

> IMHO all which is needed for an Apache 2.0
> SSL/TLS solution is that one kicks out obsolete things from mod_ssl
> (SDBM, EAPI, etc.), adjust existing code to use an SSL/TLS abstraction
> layer and the Apache 2.0 API and gift the whole code base to the ASF for
> use in Apache 2.0.
> 
> So I really hope you don't go a different way with your current
> efforts on mod_tls. Because if the existing SSL/TLS functionality in
> mod_ssl cannot be more or less provided by the new mod_tls (means:
> mod_tls has to be able to easily take over code from mod_ssl), I'm
> forced to keep mod_ssl around for Apache 2.0 as an alternative
> (Apache-SSL is no problem, because except for one feature, mod_ssl
> is a superset of Apache-SSL functionality-wise). And we certainly
> don't want this. So, please help that we find an accommodating
> approach and solution and don't move forward too fast without making
> sure the long-term goal is met (= a full-featured, clean and mostly
> backward-compatible SSL/TLS solution for Apache 2.0)...

I'm not sure that "backward-compatible" is a design aim, particularly
not if "backward-compatible" means "compatible with mod_ssl".

> So, my suggestion is this:
> 
> 1. I commit the existing mod_ssl 2.8.x to httpd-2.0/src/modules/ssl/,
>    assign the copyright to the ASF, kickout all code no longer
>    necesseary because of APR, and port it to the Apache 2.0 API
>    (although the module might still not work, of course).
> 
> 2. You, in parallel, start the SSL/TLS abstraction/encapsulation layer
>    for a new mod_tls in httpd-2.0/src/modules/tls/mod_tls.[ch]
> 
> Then if mod_ssl is already working more or less in Apache 2.0 and
> your mod_tls API provides all necessary hooks, we port the stuff from
> httpd-2.0/src/modules/ssl/ssl_xxx.[ch] (the session caches, etc.) over
> to httpd-2.0/src/modules/tls/tls_xxx.[ch] by using the new mod_tls
> abstraction/encapsulation API for the SSL/TLS code you wrote.
> 
> Is this a reasonable approach to fulfill both your wishes (the
> abstraction layer) and my wishes (the kept functionality and code)?

No. What you are saying is that we can have any SSL implementation we
like so long as it is mod_ssl. 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.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"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

Mime
View raw message