[troupo]

> That doesn't inspire confidence.

The problems start even higher on the page in "The problem with popular web servers" section that doesn't inspire confidence either.

From "nginx configs can become verbose" (because nginx is not "just" a web server [1]) to non-sequiturs like "Many popular web servers (including Apache and NGINX) are written in programming languages and use libraries that aren't designed for memory safety. This caused many issues, such as Heartbleed in OpenSSL"

[1] Sidetrack: https://x.com/isamlambert/status/1979337340096262619

Until ~2015, GitHub Pages hosted over 2 million websites on 2 servers with a multi-million-line nginx.conf, edited and reloaded per deploy. This worked incredibly well, with github.io ranking as the 140th most visited domain on the web at the time.

Nginx performance is fine (and probably that's why it's not included in the static page "benchmark")

[sim7c00]

its funny he mentions unsafe code in apache and nginx and then complains about openSSL bug (one thats more than 10 years old btw).

if this is a sense of the logic put into the application, no memory safe language will save it from the terrible bugs!

[dorianniemiec]

Heartbleed might be more than 10 years old, but it was a serious vulnerability indeed...

From https://www.heartbleed.com

> The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

Also, the program being memory-safe doesn't mean it's bug-free, other bugs not related to memory safety exist (like path traversals are due to improper sanitation or checking of the input).

[sim7c00]

still doesnt have anything to do with the webservers that used openSSL. If ferror was sanely coded and super secure but used openssl (or another vulnerable library for similar purposes --- does ferron roll its own crypto??) then it would be similarly impacted. it's memory safety features not useful since its using FFI to go into openssl.

not sure if there is already a true rust TLS implementation - that might be useful for such a case but would also make the point a moot-point since its just evading the risk by not using it, not by solving the issue of memory issues being present in third-party libraries.

[dorianniemiec]

Ferron uses a different library for TLS - Rustls.

You can read how Rustls compares to other TLS implementations, when it comes to implementation vulnerabilities, from the Rustls manual: https://docs.rs/rustls/latest/rustls/manual/_01_impl_vulnera...