Timeless timing attacks and response jitter

Question

I've been researching timeless timing attacks, ie: timing attacks using concurrency rather than round trip time. Here is an article by portswigger with links to the original article by Van Goethem. Basically it says that if you pack two requests into a TCP packet for HTTP/2 or Tor, then it will cancel out network jitter. I understand how this works when going from client => server, but when the server responds the HTTP responses are in different packets again and so wouldn't they be effected by jitter on the return trip and could potentially arrive out of order? I haven't seen any mention of network jitter on the return trip from any of the articles I've read

Answer 1

Both requests are sent simultaneously, and are executed by the remote server concurrently. All the attacker needs to do is know which response came back first. Although there is jitter on the return path, they can tell at the very least which one was sent first (e.g. by TCP sequence numbers). The attack actually relies on the fact that the target server will not multiplex the response and will send each response in series. The order they come in tells the attacker which finished execution last.

The attacker doesn't need to worry about the response that was sent first "overtaking" the other response on its way back because these protocols typically contain information that ensures that packets will not be received (or at least processed) in a different order than they were intended.

This is not an attack against a specific application, and the attack is not a risk if the target server is not running any code that is vulnerable to timing attacks, but it does illustrate that existing timing attacks that were once thought to be too hard to exploit over a network may actually be exploitable.