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!).
# 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 [Isolating Proxy](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IsolatingProxy) or [Transparent Proxy](https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy)([anonymizing middlebox](https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#AnonymizingMiddlebox) only!).
The connection would look like this:
...
...
@@ -11,26 +11,26 @@ 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 =
== Severe Issues ==
# Discussion
## Severe Issues
Severe issues ultimately and instantly defeat the purpose of this idea.
=== Tor getinfo address ===
### 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.
== Normal Issues ==
=== Denial of service ===
## Normal Issues
### 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 ===
### If the adversary also controls the bridge
Then it's game over.
=== The adversary controls the Tor process in this threat model ===
### 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 ===
### 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.
...
...
@@ -41,14 +41,15 @@ This puts the bridge into a difficult position. The bridge alone is a weak defen
(3) Simply watching the Tor bridges incoming traffic would also suffice.
= Implementation =
[https://github.com/rustybird/corridor/ corridor - Tor traffic whitelisting gateway]
# Implementation
[corridor - Tor traffic whitelisting gateway](https://github.com/rustybird/corridor/)
= Comparison =
[https://www.whonix.org/wiki/Comparison_with_Others 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.
# Comparison
[Comparisons of Whonix, Tails, Tor Browser, Qubes OS TorVM and corridor](https://www.whonix.org/wiki/Comparison_with_Others) - 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.
= Source =
# Source
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.
Credits: [[BR]]
Credits:
asn and velope explained to adrelanos in #Tor the Tor control protocol 'getinfo address' command.
