Opened 8 years ago

Closed 8 years ago

#2697 closed enhancement (fixed)

Detect exit nodes running 'transparent' HTTP proxies

Reported by: rransom Owned by: mikeperry
Priority: Very High Milestone:
Component: Core Tor/Torflow Version:
Severity: Keywords: MikePerryIterationFires20110925
Cc: Actual Points: 1
Parent ID: Points: 1
Reviewer: Sponsor:

Description

One Tor exit node operator has stated that he intends to route Tor exit node traffic through a 'transparent' HTTP proxy, and that this HTTP proxy would censor non-HTTP traffic on port 80 (including SSL/TLS). The exit scanner should be improved to detect exit nodes that divert port 80 traffic through a censoring proxy so that they can be promptly marked with the BadExit flag.

Connecting to an SSL/TLS server running on port 80 should be enough to detect many of these hostile exit nodes, but we should eventually add more subtle/thorough detection methods (e.g. sending an HTTP request in which the Host HTTP header does not match the TCP address which the Tor exit node was told to connect to).

Child Tickets

Change History (11)

comment:1 Changed 8 years ago by mikeperry

Do we want to automatically BadExit all nodes running upstream transproxies? They can also be used for caching to try to improve performance, or may just be present at the upstream ISP. My old University used to run an upstream caching proxy...

We already do detect censorship of exploit info by AV systems. We can try to focus this by running an exit scanner specifically scraping computer security and exploit related search queries. That would probably get anyone running a dumb IDS censor like snort.

comment:2 Changed 8 years ago by mikeperry

Heh, I wonder if snort's IDS is dumb enough to block downloads of the snort signature files. Some rules are probably dumb enough to trip over themselves. We could also try fetching those through every exit, or ensure that "snort rule files" is one of the queries that can get randomly chosen by the scanners.

comment:3 in reply to:  1 ; Changed 8 years ago by rransom

Replying to mikeperry:

Do we want to automatically BadExit all nodes running upstream transproxies?

If we detect them, yes.

The techniques I described above will only detect proxies that are noticeably mangling user traffic.

We already do detect censorship of exploit info by AV systems. We can try to focus this by running an exit scanner specifically scraping computer security and exploit related search queries. That would probably get anyone running a dumb IDS censor like snort.

That sounds like a Good Thing to add to the exit scanner (if it's not there already), but I would also like to detect exit nodes that are (for example) accidentally censoring or redirecting traffic as a side effect of running an HTTP request logger and/or password sniffer.

comment:4 in reply to:  3 Changed 8 years ago by rransom

Replying to rransom:

Replying to mikeperry:

Do we want to automatically BadExit all nodes running upstream transproxies?

If we detect them, yes.

The techniques I described above will only detect proxies that are noticeably mangling user traffic.

More to the point: if those two techniques detect an upstream HTTP proxy, it's not transparent.

comment:5 Changed 8 years ago by tornewbie

I think he's not the one and only one going to do that ...

I've put all Amunet* family IP range ( 199.48.147.32/28 ) in my ExcludeExitNodes list since when I saw that different tor check pages ( at random and not always ) told me I was not using Tor and the IP was 199.48.147.44 ( over which no Amunet family node is running ).

comment:6 in reply to:  5 Changed 8 years ago by rransom

Replying to tornewbie:

I think he's not the one and only one going to do that ...

That's why I want the exit scanner to use at least a few HTTP proxy detection techniques.

I've put all Amunet* family IP range ( 199.48.147.32/28 ) in my ExcludeExitNodes list since when I saw that different tor check pages ( at random and not always ) told me I was not using Tor and the IP was 199.48.147.44 ( over which no Amunet family node is running ).

It sounds to me like the Amunet exit nodes are all running on a single computer with multiple IP addresses, and their operator didn't set OutboundBindAddress (or set it to the same value in multiple nodes' torrc files). What you describe is not necessarily a sign of an upstream HTTP proxy, and particularly not on a family of exit nodes that we know contains multiple Tor instances per physical computer.

Please be aware that using ExcludeExitNodes (especially if you exclude a significant set of high-bandwidth exits) can harm your anonymity.

comment:7 Changed 8 years ago by mikeperry

Points: 6

comment:8 Changed 8 years ago by mikeperry

Keywords: Bounty added

comment:9 Changed 8 years ago by ioerror

Mike - I think ooni-probe should be able to detect this case - can you describe what you'd like to see before you'd call it a positive hit?

comment:10 in reply to:  9 Changed 8 years ago by mikeperry

Replying to ioerror:

Mike - I think ooni-probe should be able to detect this case - can you describe what you'd like to see before you'd call it a positive hit?

See the description. rransom created this bug, talk to him if you feel the description is inadequate.

comment:11 Changed 8 years ago by mikeperry

Actual Points: 1
Keywords: MikePerryIterationFires20110925 added; Bounty removed
Points: 61
Resolution: fixed
Status: newclosed

Ok, this is fixed in origin/master. You can now specify:

./soat.py --ssl --target=ip:80

and it should scan the whole network with that IP.

See the soat readme for more details:
https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/ExitAuthority/README.ExitScanning

Note: See TracTickets for help on using tickets.