Some excerpts:
> The "Oddly, sometimes the connection would succeed" sentence is a red flag sentence. If you are inclined to be paranoid, there is indeed a way to hide a real attack in what looks like a simple ntohl() bug here.
> This "sometimes"connection behavior is often seen in tagging attacks, where the adversary abuses Tor's AES-CTR mode stream-cipher-style properties to XOR a tag at one end of a circuit, and undo that tag only if the other endpoint is present. In this way, only the connections that actually succeed are those that the adversary is certain that they are in both positions in the circuit (to perform Guard discovery, or if they are the Guard relay, to confirm deanonymization).
> If you want to hide your tagging attack as what looks like a simple ntohl() bug here, you send your intro2 with the reverse IP address. Then, when your middle node suspects a candidate rend cell (via timing + circuit setup fingerprinting, to have a guess), it can confirm this guess by undoing the tag by XORing the cipherstream with ntohl(ip) XOR ip.
> <snip>
> Aka a correctly performing rend cell tag hidden in what looks like a very common networking bug.
> This cipherstream tagging weakness has had a few proposals to fix, most recently: https://gitweb.torproject.org/torspec.git/tree/proposals/295...
> BUT DON'T PANIC: There is also an alternate explanation for the "sometimes succeed" red flag in this particular case, other than a tagging attack.
> <snip>
> So most likely, this is just a poorly written Tor client, but there still is the possibility that it is an attack cleverly disguised as a poorly written Tor client.. :/
> It may be a good idea for Neal's/our monitoring infrastructure to keep an eye on this behavior too, for this reason, to test for the side channel usage + rend XOR "correction" vs just dumb bug that is sometimes connecting by getting lucky (and thus never properly reverses the rend IP address). If this is indeed just a bug, when these rends do succeed, the IP address should never be correct.
> The way to do that would be to build rend circuits using 3rd hops that you (the service operator) control, so that that 3rd hop can check if the rend succeeds because the TLS connection happened to be open (benign behavior) or because the reversed ntohl() got corrected somehow (attack).
0) https://lists.torproject.org/pipermail/tor-dev/2020-February...
1) https://lists.torproject.org/pipermail/tor-dev/2020-February...