Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#17297 closed defect (fixed)

TorCheck fails on new exit egress IP not in exit DB, confusing to users

Reported by: starlight Owned by: arlolra
Priority: High Milestone:
Component: Applications/Tor Check Version:
Severity: Normal Keywords:
Cc: karsten Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I've seen this several times and finally
figured out what was behind it. Confusing
and disturbing.

Current/recent example:

Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4

OR ip 178.33.157.6

exit ip 31.7.58.37

Not present in ExoneraTor DB as-of 2015-10-07 16:46 UTC.

TBB said

Something Went Wrong!
Tor is not working in this browser.
For assistance, please contact help@….

Problem should be mitigated somehow.

Child Tickets

Change History (11)

comment:1 Changed 4 years ago by starlight

TBB 5.0.3 Linux x86_64
tor-0.2.6.10

Have seen this in the past under
Windows TBB as well.

comment:2 Changed 4 years ago by s7r

Cc: karsten added

Let's figure out if this is a bug first.

It could be only a limitation of the exit-list, since the only way we can truly discover all the exit IP addresses is to exit via each and every exit relay. But even so, some relays have more than 1 exit IP address, some might change their exit IP address on the fly or after we check it, some could use VPNs / proxies for certain routes, etc. so the exit list will never be 100% accurate.

I have an example that it works sometimes (or probably most of the times):

Check for example:
PrivacyRepublic0001 178.32.181.96
PrivacyRepublic0002 178.32.181.97
Both exit with IP: 37.187.129.166

It actually works very good, when you connect to check.torproject.org
it says OK > you are using Tor.

Also, Exonerator (onionoo) knows how to handle it too:
https://exonerator.torproject.org/?ip=37.187.129.166&timestamp=2015-10-10

It will even return the correct results on atlas:
https://atlas.torproject.org/#search/37.187.129.166

CC'ing Karsten as this is somehow onionoo related.

comment:3 Changed 4 years ago by starlight

Yes, realize that it does apparently work in most cases.

One thing I noticed is that the problem relay does
not have a "reject" line in the exit policy for
the egress source IP. Saw some verbiage somewhere
(don't remember where) that hints possibly
this is required by/for the exit-finder logic.

Started a tor-relays thread on the issue/question

https://lists.torproject.org/pipermail/tor-relays/2015-October/007921.html

comment:4 Changed 4 years ago by karsten

TorDNSEL had an issue a few days ago where its tor process was killed, preventing it from scanning new relays. That issue was resolved on 2015-10-10 at around 10:00 UTC. Could that be related?

comment:5 Changed 4 years ago by starlight

The example given continues to fail TorCheck.

comment:6 Changed 4 years ago by starlight

Severity: Normal

Example relay sill not listed:

Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4

Seems to me the exit scanner has a bug here, no doubt.

comment:7 Changed 4 years ago by starlight

Priority: MediumHigh

This bug has a serious non-obvious impact that
potentially affects all Tor exit operators.

Due to exit-list inaccuracies, the popular SecToor list
operates a /24 DNSBL that some service providers use
for blocking access:

http://www.sectoor.de/tor.php#en-listed-net

This /24 list can cause operators difficulty
with their ISPs due to collateral damage to
other customers in the same address block
as their exit operates.

While it is obvious that service providers
should not use this list at all, it's also
obvious that not everyone engages common-sense
in such matters.

Removing the problem should make it possible
to convince SecToor to decommission the
netblock DNDBL.

comment:8 Changed 4 years ago by starlight

Looking further it becomes apparent that TorDNSEL and
all other critical exit "scanners" are not actually
"scanning" anything. They rely on published exit
policies to determine exit IP addresses.

This is a fundamental design defect as the approach
is not reliable and never will be reliable. Is
simple for an exit operator to override the exit
policy in torrc, and if that capability were
removed nothing prevents hacking of the code
to the same effect.

The correct approach is to actually scan the
network periodically while making note of the
SOCKS connection source IP and passing this
information to a scan receiver daemon/thread
via a cryptographically signed message in order
to detect and properly document NAT translations.
The implementation must take into account that
a single exit relay may have several exit IPs
that will be employed over time.

The negative consequences of unreliable exit
IP documentation includes especially problems
of perception and reputation for exit node
operators, who do not enjoy investing substantial
time and money in a relay only to encounter
trouble with their ISP due to the common use of
unreliable alternative lists such as SecToor
/24 which impose collateral damage to
uninvolved, innocent third parties.

Any collaterally damaged third-parties
encountering network blocks caused by
a neighboring Tor exit are correct to
feel abused the the situation.

It seems that several alternative exit scanners
exist, including

https://n0where.net/tor-exit-relay-scanner-exitmap/

and it is reasonable to assert that one of these
should be deployed in place of the current unacceptably
broken system.

comment:9 Changed 4 years ago by arlolra

Resolution: fixed
Status: newclosed

Thanks for reporting and sorry for being slow.

Pretty sure this particular instance was the result of TorDNSEL's tor process being killed, as suggested by karsten in #comment:4.

They rely on published exit policies to determine exit IP addresses.

No, TorDNSEL takes the same approach as the alternative you linked to, exitmap.

From the project description,

Previous DNSELs scraped Tor's network directory for exit node IP addresses, but this method fails to list nodes that don't advertise their exit address in the directory. TorDNSEL actively tests through these nodes to provide a more accurate list.

See https://www.torproject.org/projects/tordnsel.html.en

comment:10 Changed 4 years ago by starlight

Thank you for the update.

Happy to learn the design is there already, I must have been looking at an old version of TorDNSEL or missed that both approaches are utilized.

The Bywadu relay inspiring this ticket continued to exhibit the unlisted exit IP for something like two weeks after the scanner was restarted. Subsequently it was flagged as BadExit and then disappeared. My guess from the BadExit marking is that this relay was gaming the exit scanner (reasons for the BadExit flag are not published).

In the future when such relays appear they should be directly reported to the bad exit mailing list; I'll be certain to do that.

comment:11 Changed 4 years ago by arlolra

The Bywadu relay inspiring this ticket continued to exhibit the unlisted exit IP for something like two weeks after the scanner was restarted. Subsequently it was flagged as BadExit and then disappeared. My guess from the BadExit marking is that this relay was gaming the exit scanner (reasons for the BadExit flag are not published).

It got BadExit'd with #17303. The redirection described there may in fact be the real reason why TorDNSEL was never able to resolve the correct IP for that node.

Note: See TracTickets for help on using tickets.