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. Cheers and have a nice weekend, Stefan
