'''This isn't a tutorial/advice. It's merely about researching and documenting an idea. The idea was good but ultimately didn't work out.
A Bridge Firewall is defined as a gateway, which only accepts traffic to some defined Tor bridges (ex: using iptables). This can be either implemented in hardware or as a virtual machine. It would make most sense to use it in conjunction with an Isolating Proxy or Transparent Proxy (anonymizing middlebox only!).
The connection would look like this:
client computer -> Tor gateway -> Bridge Firewall -> Tor bridge
The theory was, that if the Tor router ever gets compromised by an adversary (ex: exploit against the Tor process), that the Bridge Firewall will prevent the adversary to find out the clients real IP address. This is due to adversaries inability to connect to any other IP addresses than the Tor bridges. This assumes the Tor bridges are trustworthy.
Severe issues ultimately and instantly defeat the purpose of this idea.
Tor getinfo address
Even though the Tor gateway is NATed, Tor can find out its own real external IP address through the Tor protocol as described here: https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l2716
The 'getinfo address' Tor control protocol command demonstrates this.
Denial of service
Obviously once the Tor process is compromised, the adversary is in position for a complete denial of service. This is the least of the worries.
If the adversary also controls the bridge
Then it's game over.
The adversary controls the Tor process in this threat model
Even if the bridge is trustworthy, a compromised Tor process would allow the adversary to decide which middle node and which exit node the adversary wants to use. Therefore the adversary could choose nodes under its control.
The adversary can also find out the IP of the bridges
It's safe to assume that an adversary in position to compromise the Tor process will also be motivated to setup its own malicious Tor middle node. Once the adversary has done that, the IP address of the bridge can be found out.
This puts the bridge into a difficult position. The bridge alone is a weak defense. It opens up for a number of attacks.
(1) The adversary could try to compromise (hack) the Tor bridge. If that succeeds, then it's game over.
(2) Depending on who the adversary is, also social (threatening) or legal attacks against the Tor bridge admin are possible.
(3) Simply watching the Tor bridges incoming traffic would also suffice.
Comparisons of Whonix, Tails, Tor Browser, Qubes OS TorVM and corridor - not a pure bridge firewall - by default it limits connections to any Tor relay - but it as a setting to limit connections to specified bridges.
Mostly written at the end of 2012 by Patrick Schleizer (adrelanos). This wasn't Patrick's idea. Patrick read it somewhere else and don't remember where it was and found it worth documenting here in detail.
asn and velope explained to adrelanos in #Tor the Tor control protocol 'getinfo address' command.