In the upcoming curl 8.6.0 release, we’ll ship a new, experimental HTTP/3 (QUIC) implementation using the new OpenSSL 3.2.0 QUIC stack. So, I took a look at what performance numbers I am seeing, to give you an idea what you will get.

Of course, there are no objective benchmarks. Things may behave different in your settings. I may be holding things wrong. The measurements shown below are also just from this point in time. We continue to work on this, cooperating with projects like ngtcp2 and OpenSSL for future improvements. It might look different in the near future. Anyways, that being said…

On 2023年10月19日 the project released version 2.4.58 of Apache httpd. 3 CVEs have been fixed, 2 low and 1 moderate. I describe the changes done by me below.

CVEs

The interesting one is CVE-2023-45802 which I described in my blog about the HTTP/2 Rapid Reset.

Changes

mod_http2, HTTP/2 frontend

WebSockets

I added support for bootstrapping WebSockets via HTTP/2, as described in RFC 8441. A new directive ‘H2WebSockets on|off’ has been added. The feature is not enabled by default for compatibility reasons.

The HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487 has made the news last week. For a good overview of what Cloudflare experienced and how they responded, I recommend HTTP/2 Rapid Reset: deconstructing the record-breaking attack by Lucas Pardue and Julien Desgats.

Apache httpd Impact

I am assuming you are by now somewhat familiar with what the attack is (if not, read the Cloudflare blog).

This is a Denial-of-Service attack. No private data is exposed, nothing is infected or compromised. Vulnerable infrastructure is prevented from doing its job. That may be annoying or very critical, depending on the deployment. Read: my personal website vs. the control center of a nuclear power plant.

Recently I had a customer reporting stalls in his Apache httpd installation. Those were happening on HTTP/2 requests. It took minutes before a response was sent to the client. What was going on?

The installation used Apache as a reverse proxy for an application server, a very common setup, and the app server used Server Sent Events (SSE) with browser clients. SSE are GET request that are meant to run for a very long time (in HTTP’s definition of “long”). Whenever something happens in the app server that the client should know about, it sends a small JSON piece in the response body. The request is left open until either server or client decides to drop it.

You might have heard about the ACME 0-day exploit in acme.sh (fixed in the latest release) and Matt Holt, who discovered it, has written an excellent blog about it, where you can read all the details.

In the second part of his blog, he gives general security advice and opinions on technology in regard to ACME implementations and deployments. Given that he and me and on different spectrum in the Holy Campaign on Memory Safety, I feel some points misrepresented or left out.