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.
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.