That Evolution mail caching behaviour is really sketchy. I wonder if it could be used for an exploit in the right scenario. If nothing else, it’s a good way to make an email that looks completely different depending on which client it’s opened in.
I don't think this was done on purpose. If the query string is "?a=b" that's fine, and it's used in the cache filename. But if the query string is "?a" then it's excluded from the cache filename.
Either way, the correct full URL is fetched with the full query string. It's just how it's cached that is affected.
I mean these are the same people who left their website totally unsecured. I bet they’re training their own LLM and they probably have never heard of this type of attack.
I love this, thanks for sharing. When I failed to get a measurable time difference myself I was worried I might just be doing something wrong and it'd get flagged the moment I published my research, so it's great to get confirmation from other people.
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!
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.
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?
Anyway this will be clear once it’s published.