LetsDefend: HTTP/2 Rapid Reset — why the web server died at go-live

Third time's a charm — I recorded this one more than once!

Here's the scenario. Something was tested in the development environment and it worked fine. Then it went live, and the web server stopped serving. They're using HTTP/2. Our job is to analyse the capture and work out what happened.

What cipher suite is used in the TLS packets?#

If you don't know what a cipher suite is, that is completely fine. Google "cipher suite examples" first so you know what you're looking for — it's just a set of rules telling the server and client how to encrypt the data.

Then think about the handshake. The client offers the suites it supports, and the server picks one in its reply. So the answer lives in the Server Hello.

tls

Pick any TLS packet → Transport Layer Security → Server Hello → and there's the cipher suite. I open every single expandable thing, every time. It's slower and I find more.

Don't confuse it with the certificate signature algorithm. You'll also see an RSA/SHA identifier down in Certificate Verify. Those are two different jobs: the cipher suite secures the connection, the signature algorithm validates the certificate. Worth reading up on PKI if that distinction is fuzzy.

What is the full URL requested?#

Look at the HTTP/2 GET request and read the headers — the full URL is in there.

There's a second route to it too. The challenge hint gives you the IP, you can see the path in the request, and the port shows up in the packet detail. Stitch those together and you get the same answer: it's over 443.

What is the name of the server's hosting library?#

Don't know what a hosting library is? Neither did I, once. Here's a trick to build the intuition.

Open any website in Chrome → DevTools → Network → the very first request → Response Headers. You'll see a server header, and often x-powered-by. That's the shape of what we're hunting for. (For JavaScript it's usually Express, for Python it's Flask.)

So back in Wireshark, find the server response header. I picked a packet with a decent number of HTTP requests to save myself work, opened it up, and found a 404 response carrying the server header: nghttpd — the C library used for HTTP/2.

Didn't recognise it? Neither did I. I googled it. That's the job.

Which stream type triggered the attack?#

Inspect the HTTP/2 request and walk the frame types. Stream settings, no. Stream headers, no. Stream data, no.

RST_STREAM. That's the one.

Here's why that's a red flag rather than just an answer. An established connection suddenly dropping is not normal behaviour. There's a known technique where an attacker floods a connection with resets — and if you keep scrolling the capture, you can see them repeating over and over. Somebody is interrupting connections the moment the service goes live.

What status code did the server return?#

404. You can read it straight off the response.

Quick refresher: 200s are fine, 300s are redirects, 400s are client errors, 500s are the server's fault.

How many requests in total?#

Do not count them by hand.

Statistics → filter by the protocol you care about, and Wireshark gives you the count. That's it.

Which stream type closed the connection?#

This was my favourite question of the whole challenge.

It's the end of the conversation, so I went to the last frame. The stream type is GOAWAY. Which is a genuinely excellent name for a frame that closes a connection.

What is the CVE?#

I did not know this by heart, and there's no reason you should either.

Search for "HTTP/2 rapid reset". It comes straight back: CVE-2023-44487 — the HTTP/2 Rapid Reset attack. Attackers open streams and immediately cancel them with RST_STREAM, over and over, forcing the server to do work for requests that no longer exist.

Which explains the whole scenario. It was fine in dev because nobody was attacking dev.

What did we learn?#

1. Wireshark filters are lowercase. tls, not TLS.
2. The Server Hello is where the chosen cipher suite lives.
3. A cipher suite and a certificate signature algorithm are different things.
4. The server response header names the software — check it in DevTools on any site to build the instinct.
5. RST_STREAM floods mean rapid reset. GOAWAY closes the connection.
6. Use Statistics for counts. Never count packets manually.
7. Google the CVE. Always.

This did not take ten minutes to solve. It took a lot longer, and I had to look plenty of it up.

That is normal. In a real security career you will spend a large amount of time researching and consulting your peers, and that is not an ego thing — cybersecurity keeps evolving and it is on you to stay current.

Keep going!