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

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@rt.torproject.org.

Problem should be mitigated somehow.

added component::applications/tor check owner::arlolra priority::high resolution::fixed severity::normal status::closed type::defect labels

TBB 5.0.3 Linux x86_64 tor-0.2.6.10

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

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.

Trac:
Cc: N/A to karsten

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

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?

The example given continues to fail TorCheck.

Example relay sill not listed:

Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4

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

Trac:
Severity: N/A to Normal

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.

Trac:
Priority: Medium to High

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.

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

Trac:
Status: new to closed
Resolution: N/A to fixed

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.

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 (moved). The redirection described there may in fact be the real reason why TorDNSEL was never able to resolve the correct IP for that node.

closed

mentioned in issue #18505 (moved)