Add it in :-)
> On Nov 24, 2021, at 4:46 AM, ste...@eissing.org wrote:
>
> Coming back to this. Since there was no feedback on my post: are people
> just too occupied/opposed/not interested?
>
> Curious,
> Stefan
>
>> Am 18.11.2021 um 18:48 schrieb ste...@eissing.org:
>>
>> How would you feel about adding mod_tls
>> (https://github.com/abetterinternet/mod_tls) as an experimental module to
>> Apache httpd?
>>
>> 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)
>> - 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,
>>
>> Stefan
>>
>> PS. On a more personal note:
>> The way this project turned out was a clean separation between C and Rust.
>> The API offered by rustls-ffi is colored by Rust's immutability/borrowed
>> memory concepts, but there is nothing Rust special the C code needs to do.
>> It remains C code. It remains in our core competence.
>>
>> Working with the rustls people has been nice and productive. The only thing
>> I can report is that they come from the client TLS side and specific server
>> needs require some explaining. There are things we can offer to them here.
>>
>> There are a lot of political things going on right now around OpenSSL and I
>> definitely want to stay out of that. Again, we can offer this without having
>> to switch ourself. Even better, customers can use this without needing to
>> switch completely, as it co-exists. I think that fits into the concepts our
>> server is designed with.
>>
>> Thanks for your time.
>>
>
