Hi,
a wiki page with a description of a Bridge Firewall has been created by me:
https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/BridgeFirewall
> '''This isn't a tutorial/advice. It's merely about researching and documenting an idea. It has not been thoroughly discussed.
>> [[TOC(noheading, depth=1)]]
>> = Introduction =
> 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 [https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IsolatingProxy Isolating Proxy] or [https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy Transparent Proxy] ([https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#AnonymizingMiddlebox 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.
>> = Discussion =
> == 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 it's 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 it's 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.
>> = Source =
> This wasn't adrelanos's idea. Adrelanos read it somewhere else and don't remember where it was.
Please feel free to comment on the idea, if it can be improved, if there
are even more devastating attacks, if my considerations are faulty
somewhere or anything else.
Cheers,
adrelanos