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, 
- 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:

or have hooks like;

The obvious thing how we could provide for this is to offer these functions and 
hooks in the core server. There would be

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,


Reply via email to