> 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,
Stefan
>
> Regards,
> Graham
> —
