On 2/12/21 4:55 PM, 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_look
>   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.

Sounds reasonable. I think we gave up a long time ago on having mod_ssl being 
able to support different SSL implementations (real
different ones like Mozilla not ones like LibreSSL) / libraries as it made 
things complex and hard to maintain and given the usage
of OpenSSL the benefits were quite low. Maybe mod_ssl could evolve / split long 
term into a generic SSL module that provides some
high level infrastructure API like above and "provider" modules that implement 
that for a particular SSL implementation / library.
Hence this split would result in mod_ssl and mod_ssl_openssl for our code base.
Maybe the "provider" modules could still offer some additional features beyond 
that generic API that are possible with the backing
SSL implementation.



Reply via email to