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

It worked in dev and fell over in production. Reading the TLS handshake, finding the RST_STREAM flood in the capture, and landing on the CVE.

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.

Careful

#

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.

Tip

#

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

#

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

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

#

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

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.

#

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

#

Do not count them by hand.

#

This was my favourite question of the whole challenge.

#

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

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

#

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!

Contents

Skills covered

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