> Am 12.02.2021 um 19:28 schrieb Eric Covener <cove...@gmail.com>:
>
> On Fri, Feb 12, 2021 at 10:55 AM ste...@eissing.org <ste...@eissing.org>
> wrote:
>>
>> As you might know, I have started writing an Apache module to bring SSL
>> using the Rust based rustls library to the server. Currently, I have base
>> connection filter working and can serve requests. Nothing fancy, but the
>> Rust lib is loaded and does the job.
>>
>> My goal for this project is to have a module that will co-exist with
>> mod_ssl, because:
>> - rustls is not openssl in terms of functions and tweaks it supports. There
>> will be many people that rely on those or have backends with older TLS
>> versions which rustls cannot serve.
>> - Some people might want to use this selectively on some (maybe the publicly
>> exposed) ports of their installations.
>>
>> So, it will _not_ pretend to be mod_ssl. It will have its own configuration
>> directives. Which also means it will not provide sneaky optional functions,
>> such as:
>> ssl_var_lookup
>> ssl_is_https
>> ssl_proxy_enable
>> ssl_engine_disable
>> ssl_engine_set
>>
>> or have hooks like;
>> add_cert_files
>> add_fallback_cert_files
>>
>> The obvious thing how we could provide for this is to offer these functions
>> and hooks in the core server. There would be
>> ap_ssl_var_lookup
>> ap_is_https
>> ap_ssl_proxy_enable
>> etc.
>>
>> implemented as hooks where mod_ssl and mod_tls would register and give
>> information on their respective connections or on the proxy settings they
>> are configured with. mod_ssl would continue to offer its optional functions
>> as it does now. But the uses of these in our own modules we would adapt.
>
>>
>> This would be nothing specific for the module I write, but available to
>> anyone who wants to provide a SSL implementation. It might be a way ahead
>> for a mod_ssl2 that gets rid of old openssl APIs and SSL3xxx things. Or it
>> might be that someone writes a mod_ressl without needing to listen to its
>> faked openssl version defines etc.
>>
>> Does this sound like a good development for httpd? Are there alternatives or
>> risks that I have missed? Would very much like to hear from you.
>
> There are existing third-party SSL modules that implement these
> optional functions (at least mod_nss and closed source mod_ibm_ssl).
>
> I don't think 2.4 should stop calling them and break this integration
> point that's in use. If there's some improvement that allows two SSL
> modules to both be loaded and not conflict I think it should tolerate
> the case where there's a single old optional function (only) loaded
> and expressions (or logging or SSLProxyEngine stuff) should work the
> same.
I agree. My more detailed proposal would be:
Use cases:
A backward compatibility for existing ssl modules that offer mod_ssl's optional
functions/hooks
B backward compatibility for existing modules that call mod_ssl's optional
functions/hooks
C use of new ap_ hooks by modules aware of them
Provide A/B/C by replacing optional functions with core's own that call into
the new hooks. Adding a hook callback that calls earlier registered optional
functions.
Example:
Now:
APR_DECLARE_OPTIONAL_FN(int, ssl_is_https, (conn_rec *)); // in
mod_ssl/mod_nss/mod_ibm_ssl
Then:
APR_DECLARE_OPTIONAL_FN(int, ssl_is_https, (conn_rec *)); // in http_ssl.h
AP_DECLARE_HOOK(int, is_https,(conn_rec *c)) // the new core hook
#ifndef APACHE_HTTP_SSL_H // in mod_ssh.h
APR_DECLARE_OPTIONAL_FN(int, ssl_is_https, (conn_rec *));
#endif
after modules->register_hooks, the core:
// Pick up old modules and add them to hook (use case A)
old_fn = APR_RETRIEVE_OPTIONAL_FN(ssl_is_https);
if (old_fn) { register call to old_fn in new hook 'is_https' }
// Always override the optional fn to call the hook (use case B)
static int ssl_is_https(conn_rec *c) { call new hook }
APR_REGISTER_OPTIONAL_FN(ssl_is_https);
This would not allow two old, unaware ssl modules to be loaded (which also does
not work today), but it would allow mixing of one old with one (or more) new.
If I am not mistaken...
- Stefan
