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

Reply via email to