Occasionally I run into a relay such as
Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4
OR ip 178.33.157.6
exit ip 31.7.58.37
Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor. TorCheck in glaring unhappy RED spits
Something Went Wrong! Tor is not working in this browser. For assistance, please contact help@rt.torproject.org.
Does anyone know why this happens? Many exit nodes have ips that differ from the OR ip and work fine. Don't see any bug reports on it.
Does the operator have to submit these manually? I had the impression that TorCheck actually build the DB for ExoneraTor.
At 13:29 10/8/2015 -0400, starlight.2015q3@binnacle.cx wrote:
Occasionally I run into a relay such as
Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4 OR ip 178.33.157.6 exit ip 31.7.58.37
Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor. TorCheck complains. . .
Is it perhaps because the exit policy for the above and similar relays does not contain a "reject" line for the alternate IP, as in
reject 178.33.157.6:* # present reject 31.7.58.37:* # missing
The OR-address "reject" is automatic and I'm guessing that if one uses OutboundBindAddress in the config that would also be included.
But if 'torrc' does not contain the alternate interface IP(s) does the 'tor' daemon recognize alternate egress source interfaces or does one have to configure the "reject" lines manually?
Have not come across any documentation on this. Would it be considered a bug in the Tor daemon that it does not gather multi-home source IPs for "reject" in the exit policy?
If a relay is missing an egress IP "reject" line and has no contact, would that be a serious misconfiguration that indicates BadExit should be assigned?
On 11 Oct 2015, at 13:47, starlight.2015q3@binnacle.cx wrote:
At 13:29 10/8/2015 -0400, starlight.2015q3@binnacle.cx wrote:
Occasionally I run into a relay such as
Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4 OR ip 178.33.157.6 exit ip 31.7.58.37
Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor. TorCheck complains. . .
Is it perhaps because the exit policy for the above and similar relays does not contain a "reject" line for the alternate IP, as in
reject 178.33.157.6:* # present reject 31.7.58.37:* # missing
The OR-address "reject" is automatic and I'm guessing that if one uses OutboundBindAddress in the config that would also be included.
Unfortunately not (see below).
But if 'torrc' does not contain the alternate interface IP(s) does the 'tor' daemon recognize alternate egress source interfaces or does one have to configure the "reject" lines manually?
As of 0.2.7.3, tor blocks the following addresses by default (ExitPolicyRejectPrivate): * the configured or autodiscovered IPv4 address (Address or resolve_my_address()) * the configured IPv6 address (first IPv6 ORPort entry) * the publicly routable IPv4 or IPv6 address(es) of every interface on the server, if available. (Local and private addresses are already blocked by ExitPolicyRejectPrivate.)
It’s my opinion that this covers the majority of use cases for multihomed, multi-IP, or different internal/external address (that is, NAT or similar) relays.
This change was tracked and merged as #17027: policies_parse_exit_policy_internal should block all IPv4 and IPv6 local addresses. https://trac.torproject.org/projects/tor/ticket/17027 https://trac.torproject.org/projects/tor/ticket/17027 This change is being considered for backport to 0.2.6 as a security fix.
The behaviour as of 0.2.7.2-alpha and below was to only block the configured or autodiscovered IPv4 address.
However, a look through the Tor manual page suggests the following additional candidate addresses: * OutboundBindAddress * ControlPort / ControlListenAddress * SOCKSPort / SOCKSListenAddress * TransPort / TransListenAddress * NATDPort / NATDListenAddress * DNSPort / DNSListenAddress * ORPort / ORListenAddress (IPv4 entries or subsequent IPv6 entries) * DirPort / DirListenAddress
We could block these by looking at OutboundBindAddressIPv4_/OutboundBindAddressIPv6_ and get_configured_ports(). (I’ve added a note about these changes to issue #17027.)
I’d also consider the IPv6 address (if available) from Address (if an IPv6 literal [this doesn’t work at present] or DNS name), but Address isn’t used by Tor to find IPv6 addresses, so I’m not sure how useful this is.
Have not come across any documentation on this.
Please see the Tor 0.2.7.3 manual page under “ExitPolicyRejectPrivate” (the version on the Tor website is too old) or Trac bug #17027. https://trac.torproject.org/projects/tor/ticket/17027 https://trac.torproject.org/projects/tor/ticket/17027
Would it be considered a bug in the Tor daemon that it does not gather multi-home source IPs for "reject" in the exit policy?
Yes (see above).
If a relay is missing an egress IP "reject" line and has no contact, would that be a serious misconfiguration that indicates BadExit should be assigned?
There may be valid reasons why an operation explicitly wants to allow Tor users to exit to their own server. In this case, they would have to make sure that local services don’t assume that local connections are trusted.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Occasionally I run into a relay such as
Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4
OR ip 178.33.157.6
exit ip 31.7.58.37
Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor. TorCheck in glaring unhappy RED spits
Something Went Wrong! Tor is not working in this browser. For assistance, please contact help@rt.torproject.org.
Does anyone know why this happens?
Such "non declared" exit IP addresses (OR IP != exit IP) are found by exiting through every single exit relay to detect its exit IP.
Since exits can change their exit IP address at any time the exit list can never be 100% accurate by design.
On 11 Oct 2015, at 22:27, nusenu nusenu@openmailbox.org wrote:
Occasionally I run into a relay such as
Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4
OR ip 178.33.157.6
exit ip 31.7.58.37
Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor. TorCheck in glaring unhappy RED spits
Something Went Wrong! Tor is not working in this browser. For assistance, please contact help@rt.torproject.org.
Does anyone know why this happens?
Such "non declared" exit IP addresses (OR IP != exit IP) are found by exiting through every single exit relay to detect its exit IP.
Since exits can change their exit IP address at any time the exit list can never be 100% accurate by design.
https://collector.torproject.org/formats.html#exit-lists https://collector.torproject.org/formats.html#exit-lists
Isn't this a bug in TorCheck? It assumes that every relay has its ORPort IP as its Exit IP (OutboundBindAddress), and most likely also assumes that each exit only has one IP.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Don't know if we can call it a bug. It appears to be working, real exit IP addresses are discovered.
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 (and onionoo) knows how to handle it too: https://exonerator.torproject.org/?ip=37.187.129.166%C3%97tamp=2015-10-10
It will even return the results on atlas: http://atlas777hhh7mcs7.onion/#search/37.187.129.166
On 10/11/2015 2:27 PM, nusenu wrote:
Occasionally I run into a relay such as
Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4
OR ip 178.33.157.6
exit ip 31.7.58.37
Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor. TorCheck in glaring unhappy RED spits
Something Went Wrong! Tor is not working in this browser. For assistance, please contact help@rt.torproject.org.
Does anyone know why this happens?
Such "non declared" exit IP addresses (OR IP != exit IP) are found by exiting through every single exit relay to detect its exit IP.
Since exits can change their exit IP address at any time the exit list can never be 100% accurate by design.
You are checking the wrong IP and not reading the post.
At 01:45 10/12/2015 +0300, s7r wrote:
Check for example: PrivacyRepublic0001 178.32.181.96
At 13:29 10/8/2015 -0400, starlight.2015q3@binnacle.cx wrote:
Occasionally I run into a relay such as
Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4 OR ip 178.33.157.6 exit ip 31.7.58.37
Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor.
...
MANY EXIT NODES HAVE IPS THAT DIFFER FROM THE OR IP AND WORK FINE. . .
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
I know those aren't related to the relay in your report, I only provided them as an example that it works sometimes (the relay in your report is in the same datacenter with the ones in my example so the networking setup could be similar). Sorry if the email looked like I misread the post. As I said, maybe this is just the limitation of the exit-list by its design.
Good that you've opened a ticket on trac - maybe there's something we can do about it.
On 10/12/2015 1:53 AM, starlight.2015q3@binnacle.cx wrote:
You are checking the wrong IP and not reading the post.
At 01:45 10/12/2015 +0300, s7r wrote:
Check for example: PrivacyRepublic0001 178.32.181.96
At 13:29 10/8/2015 -0400, starlight.2015q3@binnacle.cx wrote:
Occasionally I run into a relay such as
Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4 OR ip 178.33.157.6 exit ip 31.7.58.37
Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor.
...
MANY EXIT NODES HAVE IPS THAT DIFFER FROM THE OR IP AND WORK FINE. . .
tor-relays@lists.torproject.org
-
nusenu -
s7r -
starlight.2015q3＠binnacle.cx -
Tim Wilson-Brown - teor