(portswigger.net)

181 points saikatsg | 1 comments | 21 Nov 24 18:08 UTC | HN request time: 0.2s | source

Show context

marcus_holmes ◴[22 Nov 24 01:36 UTC] No.42210400[source]▶

>>42206955 (OP) #

I'm curious that he appears to completely ignore the network latency/jitter on the return path. How does this work?

albinowax_ ◴[22 Nov 24 08:54 UTC] No.42212208[source]▶

With the single-packet attack, you look at the order that the responses arrive in, instead of the time they take to arrive. Since the responses are on a single TLS stream, they always arrive at the client in the order that the server issued them in. Hope that makes sense!

replies(1): >>42216898 #

tptacek ◴[22 Nov 24 19:58 UTC] No.42216898[source]▶

>>42212208 #

I take them to be asking why jitter on the return path doesn't confound the results, regardless of the trick used to ensure they arrive concurrently (and cancel out the jitter on the ingress path). The responses to single-packet H2 attacks are not themselves single packets.

replies(1): >>42218543 #

1. marcus_holmes ◴[23 Nov 24 00:58 UTC] No.42218543[source]▶

>>42216898 #

Yes to both!

It makes sense that the packets return in an order that provides information, but we're talking about timing differences of a few ms; as tptacek says I would expect that there's some network jitter on the return path that has to be allowed for with timings this small?

Yet apparently not - obviously the attacks are working. Does he somehow know when the response left the server?

↑

Listen to the whispers: web timing attacks that work