I think most things are within your ability based on recent successes! We’re loving your work. Here’s another possibility:
How about implementing the Vanguards Control Port Add-On server side? Works with Tor 3.3 or 3.4 series.
A traffic analysis side channel can be used to confirm that the malicious node is in fact part of the rendezvous circuit, leading to the discovery of that onion service’s guard node. From that point, the guard node can be compromised, coerced, or surveilled to determine the actual IP address of the onion service or client.
The Vanguards Control Port Add-On
Fixing the guard discovery problem in Tor itself is an immense project – primarily because it involves many trade-offs between performance and scalability versus path security, which makes it very hard to pick good defaults for every onion service.
Because of this, we have created an add-on that can be used in conjunction with a Tor onion service server or a Tor client that accesses Tor onion services.
The add-on uses our Control Port Protocol and the corresponding Stem Library to defend against these attacks. The hope is that it will we will be able to study the performance and functionality of this feature and gather feedback before we deploy these changes in Tor for all onion services and clients.
This change to fixed nodes for the second and third layer guards is designed to force the adversary to have to run many more nodes, and to execute both an active sybil attack, as well as a node compromise attack. In particular, the addition of second layer guard nodes means that the adversary goes from being able to discover your guard in minutes by running just one middle node, to requiring them to sustain the attack for weeks or even months, even if they run 5% of the network.
Mike Perry (the guru) notes re: bridges ->
Without the vanguards addon, these same attacks will work to find the bridge your onion service is using. So using a bridge by itself is not a defense. However, using a bridge with this addon will provide some additional benefit. Namely, if the bridge is not well-known, it can help obscure the fact that your onion service server is connecting to the Tor network, because the traffic from your onion service into the Tor network will be obfuscated. If meek still works, it is probably the best option, but I think meek no longer works well because the major cloud providers started blocking it – https://arstechnica.com/information-technology/2018/04/google-disables-… – so obfs4 or basket may be the best choice. I would use two bridges.
And how this prevents some attacks compared to the normal situation ->
No, unfortunately as soon as a malicious middle node is chosen next to your guard node on one of the (many) circuits that the adversary creates, a specially timed stream of data can be used to determine that it is in fact present in the circuit and next to your guard, regardless of the number of hops in your path. See the README for more details: https://github.com/mikeperry-tor/vanguards/blob/master/README.md
No downside, all upside?