Hello Tor-Dev,
When opening Tor browser today, I opened check.torproject.org http://check.torproject.org/ and got a really confusing message https://www.fredericjacobs.com/blog/img/tor/ipv6TorCheck.png.
My assumption is that the circuit had an exit node that had (possibly multiple) IPv6-enabled, in addition to it’s IPv4. When the exit node connected to the exit node, it did so over IPv6 since check.torproject.org http://check.torproject.org/ has IPv6 addresses.
~ ❯❯❯ host check.torproject.org check.torproject.org is an alias for chiwui.torproject.org. chiwui.torproject.org has address 138.201.14.212 chiwui.torproject.org has IPv6 address 2a01:4f8:172:1b46::abba:20:1
That’s a scary warning to get in Tor browser. Any reason chiwui.torproject.org http://chiwui.torproject.org/ has an IPv6 address? Can it be disabled to avoid having people (unnecessarily) freaking out over this warning?
Thoughts?
Best,
Frederic
Frederic Jacobs lists@fredericjacobs.com wrote Wed, 17 Aug 2016 23:17:28 -0700:
That’s a scary warning to get in Tor browser. Any reason chiwui.torproject.org http://chiwui.torproject.org/ has an IPv6 address? Can it be disabled to avoid having people (unnecessarily) freaking out over this warning?
Thoughts?
I think this should be fixed by making the data that check.tpo is using more reliable rather than getting rid of a way of reaching the check service.
Here's a ticket where this is being discussed: https://trac.torproject.org/projects/tor/ticket/19843
Frederic Jacobs transcribed 3.9K bytes:
Hello Tor-Dev,
When opening Tor browser today, I opened check.torproject.org http://check.torproject.org/ and got a really confusing message https://www.fredericjacobs.com/blog/img/tor/ipv6TorCheck.png.
My assumption is that the circuit had an exit node that had (possibly multiple) IPv6-enabled, in addition to it’s IPv4. When the exit node connected to the exit node, it did so over IPv6 since check.torproject.org http://check.torproject.org/ has IPv6 addresses.
~ ❯❯❯ host check.torproject.org check.torproject.org is an alias for chiwui.torproject.org. chiwui.torproject.org has address 138.201.14.212 chiwui.torproject.org has IPv6 address 2a01:4f8:172:1b46::abba:20:1
That’s a scary warning to get in Tor browser. Any reason chiwui.torproject.org http://chiwui.torproject.org/ has an IPv6 address? Can it be disabled to avoid having people (unnecessarily) freaking out over this warning?
Thoughts?
Best,
Frederic
Hello Frederic,
That's indeed a scary warning. Removing the AAAA record for check.tpo is probably the sanest short-term solution.
Long term solutions include:
- Patching TorDNSEL [0] to add support for IPv6 addresses. This probably requires somewhat of a complete overhaul of TorDNSEL, because: 1) most of us don't speak Haskell 2) it's ancient Haskell 3) the DNSBL was designed to handle queries like 1.0.0.10.80.4.3.2.1.ip-port.exitlist.example.com.
- Patching Check [1] to use server descriptors (rather than networkstatus documents) and to additionally (in the Stem script) pull IPv6 addresses from stem.descriptor.server_descriptor.RelayDescriptor.or_addresses.
Both of those codebases need someone to love them, and contributions from volunteers feeling so inspired are highly welcome. A ticket for this is #19843, [2] although another ticket could be made since that one seems to be reporting multiple issues (and some of which are not bugs).
Thanks for pointing this out!
[0]: https://gitweb.torproject.org/tordnsel.git/ [1]: https://gitweb.torproject.org/check.git/ [2]: https://trac.torproject.org/projects/tor/ticket/19843
Best regards,
Hi,
On Thu, Aug 18, 2016 at 11:13:08AM +0000, isis agora lovecruft wrote:
- Patching Check [1] to use server descriptors (rather than networkstatus documents) and to additionally (in the Stem script) pull IPv6 addresses from stem.descriptor.server_descriptor.RelayDescriptor.or_addresses.
With IPv6 this can be more complicated, as relays may be using "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC4941) which means that these IP addresses may change often.
We should probably give some advice to relay operators to ask them to disable privacy extensions?
Thanks, Iain.
On 18 Aug 2016, at 23:06, Iain R. Learmonth irl@torproject.org wrote:
Hi,
On Thu, Aug 18, 2016 at 11:13:08AM +0000, isis agora lovecruft wrote:
- Patching Check [1] to use server descriptors (rather than networkstatus documents) and to additionally (in the Stem script) pull IPv6 addresses from stem.descriptor.server_descriptor.RelayDescriptor.or_addresses.
With IPv6 this can be more complicated, as relays may be using "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (RFC4941) which means that these IP addresses may change often.
We should probably give some advice to relay operators to ask them to disable privacy extensions?
Relays which change IPv6 addresses can be a good thing, because it allows clients to avoid Exit IPv6 blocks. But it also makes check.torproject.org unreliable.
Rather than removing a useful block-evasion feature, maybe we could redesign check.torproject.org to check a few different exit addresses?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
Thanks Fred.
On Aug 18, 2016, at 3:14 AM, Linus Nordberg linus@torproject.org wrote:
I think this should be fixed by making the data that check.tpo is using more reliable rather than getting rid of a way of reaching the check service.
Yes, working on it.
On Aug 18, 2016, at 4:13 AM, isis agora lovecruft isis@torproject.org wrote:
That's indeed a scary warning. Removing the AAAA record for check.tpo is probably the sanest short-term solution.
This was done in https://trac.torproject.org/projects/tor/ticket/19940
host check.torproject.org
check.torproject.org has address 138.201.14.212
On Aug 18, 2016, at 2:51 PM, teor teor2345@gmail.com wrote:
But it also makes check.torproject.org unreliable.
Not just check, but anything relying on the exit-addresses list, particularly ExoneraTor.
Arlo Breault transcribed 1.3K bytes:
On Aug 18, 2016, at 2:51 PM, teor teor2345@gmail.com wrote:
But it also makes check.torproject.org unreliable.
Not just check, but anything relying on the exit-addresses list, particularly ExoneraTor.
Yikes, this is a really good point. I've made a ticket for the issue in BridgeDB. https://trac.torproject.org/projects/tor/ticket/19997