3 ms·

An important aspect to #8 was the 250ms lock, that allowed you to send multiple requests while others were locked out. First I was trying to send the requests f

by sly010 14y ago

An important aspect to #8 was the 250ms lock, that allowed you to send multiple requests while others were locked out. First I was trying to send the requests from my local machine, which made it nearly impossible to get usable numbers because of the delay in the network. Before I started using level2 machine to both send and receive, I was planning to bind on every port of the level2 server to stop/slow others thus raising my own chances of hit. Luckily it didn't come to that. Even before the port number attack, I was trying to find a pattern in the request object pointer values in subsequent backtraces. This gave me the port idea. Also spent a few hours trying to exploit the Twisted HTTP client by malformed HTTP redirects (taking the over- specified Twisted version in the README as a clue).

fduran 14y ago
I thought about the possibility of somebody hogging all the local ports in the level 2 server but I read somewhere that Stripe was resetting unused ports.
rrjamie 14y ago
Yeah, the attack barely work without the lock, as you would have to rely on pure luck on getting the port delta small enough. Because of the lock, the first request you make after you get the lock was likely garbage, and then you have 250ms to get as many requests as you can. Performance here was key, since you couldn't easily do simultaneous requests so you ere limited by the number of round trips you could do in that time. Some people managed to do simultaneous requests, but you had to do more book keeping since the delta on the first responding webhook contained all the information (eg, for a failed first chunk on N requests, you would expect a difference of 2*N). You would also have to synchronize with the lock, which isn't easy. Due to load on the servers, SSL negotiation was extremely slow, so using a Keep-Alive connection was required for decent performance. My final Python implementation managed to eliminate about 4 candidate chunks/sec even under heavy load. I managed to finish #90.

by sly010 14y ago

fduran 14y ago

I thought about the possibility of somebody hogging all the local ports in the level 2 server but I read somewhere that Stripe was resetting unused ports.

rrjamie 14y ago

Yeah, the attack barely work without the lock, as you would have to rely on pure luck on getting the port delta small enough. Because of the lock, the first request you make after you get the lock was likely garbage, and then you have 250ms to get as many requests as you can. Performance here was key, since you couldn't easily do simultaneous requests so you ere limited by the number of round trips you could do in that time. Some people managed to do simultaneous requests, but you had to do more book keeping since the delta on the first responding webhook contained all the information (eg, for a failed first chunk on N requests, you would expect a difference of 2*N). You would also have to synchronize with the lock, which isn't easy. Due to load on the servers, SSL negotiation was extremely slow, so using a Keep-Alive connection was required for decent performance. My final Python implementation managed to eliminate about 4 candidate chunks/sec even under heavy load. I managed to finish #90.