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.
