> Am 24.11.2021 um 12:42 schrieb Graham Leggett <minf...@sharp.fm>:
> On 18 Nov 2021, at 19:48, ste...@eissing.org wrote:
>> How would you feel about adding mod_tls 
>> (https://github.com/abetterinternet/mod_tls) as an experimental module to 
>> Apache httpd?
> Having more choice is excellent.
>> For people who have not followed that development:
>> - it is a TLS 1.2/1.3 implementation based on rustls, 
>> https://github.com/rustls/rustls
>> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi
>> - it is itself written in C, linking all the Rust things from the rustls-ffi 
>> library
>> - it does not bring any Rust into our code base
>> - functionality wise, it is a clear subset of what mod_ssl offers via openssl
>> (e.g. no client certificates now and not as tweakable - at least for now)
> Client certs is a must for me. I know that they’re political, but my clients 
> in finance don’t care.

Understood. They might come in the future, if rustls exposes the necessary 
functionality. But mod_tls is not intended as a full replacement for everything 
mod_ssl offers. For example, rustls will never support FIPS (my understanding).

>> - it can be co-loaded and co-used with mod_ssl on different ports or 
>> front-/backend roles
>> - performance-wise, according to my plain vanilla tests, it is on par with 
>> mod_ssl
>> The decision to offer it downstream is of course then made by the distros, 
>> as usual with experimental modules. And if and how it is then used rests 
>> with the users. It is an offered alternative for people.
>> What would be the benefit to the project?
>> - we offer people an alternative. If they feel the memory safety that Rust 
>> offers is important to them, they can do it with Apache httpd for the TLS 
>> stack.
>> - we could see how people react to this and adapt our TLS offering 
>> accordingly. It being experimental, we remain free to change it. Or remove 
>> it again.
>> Organizational Things:
>> - the development was done by myself
>> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the 
>> org behind Let's Encrypt, as part of they "memory safety" initiative 
>> (https://www.memorysafety.org)
>> Feedback appreciated,
> I lean towards adding it as an httpd subproject at this level:
> https://svn.apache.org/viewvc/httpd/
> This frees you from all the complexity around experimental bits of httpd 
> compared to fully supported bits.
> This means that practically, it can be packaged through channels like EPEL 
> until it becomes stable, at which point the distros will pick it up.
> It also insulates us against external dependencies like rust. Languages wax 
> and wane, should a rust2 coming along, or another language called oxide 
> that’s better, we’re not left with aging code in our codebase. This is a 
> problem that APR solves for us for operating systems.

In its development, the arrival of mod_tls has caused changes in our server 
core. Not in any way related to Rust itself. But we added the capability to 
have more than one SSL/TLS provider in our server. So people can use whatever 
fits best for the parts they need it.

Future improvements in this area would be done easiest, if mod_tls is a module 
in our source base next to mod_ssl. API dependencies are managed better if we 
release enhanced versions together. I see no benefit for anyone involved in 
making it a separate Apache httpd subproject. It has a home on github with all 
its infrastructure.

Kind Regards,

> Regards,
> Graham
> —

Reply via email to