Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-07-05T17:47:56Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25295Torsocks only accepts IPv4 replies but Tor prefers IPv6Automap by default2021-07-05T17:47:56ZTracTorsocks only accepts IPv4 replies but Tor prefers IPv6Automap by defaultAt the moment, MapAddress .exit entries won't resolve through torsocks for me, because tor gives an IPv6 reply, and torsocks is only designed for IPv4 replies.
Torsocks gives the characteristic error `[socks5] Resolve destination buffer...At the moment, MapAddress .exit entries won't resolve through torsocks for me, because tor gives an IPv6 reply, and torsocks is only designed for IPv4 replies.
Torsocks gives the characteristic error `[socks5] Resolve destination buffer too small (in socks5_recv_resolve_reply() at socks5.c:681)` when tor replies with an IPv6 address, which it does every single time for mapaddress .exit entries for me.
**Trac**:
**Username**: fuzzyTewTor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/13043torspec lies about accepting both IPv4 and IPv6 for ORAddress lines2020-06-27T14:02:36ZIsis Lovecrufttorspec lies about accepting both IPv4 and IPv6 for ORAddress lines(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, desp...(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, despite what `dir-spec.txt` says.
The spec [says](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l1166):
```
"a" SP address ":" port NL
[Any number]
The "or-address" element as specified in section 2.1.1.
```
[and](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l587):
```
"or-address" SP ADDRESS ":" PORT NL
[Any number]
ADDRESS = IP6ADDR | IP4ADDR
IPV6ADDR = an ipv6 address, surrounded by square brackets.
IPV4ADDR = an ipv4 address, represented as a dotted quad.
PORT = a number between 1 and 65535 inclusive.
An alternative for the address and ORPort of the "router" line, but with
two added capabilities:
* or-address can be either an IPv4 or IPv6 address
* or-address allows for multiple ORPorts and addresses
A descriptor SHOULD NOT include an or-address line that does nothing but
duplicate the address:port pair from its "router" line.
The ordering of or-address lines and their PORT entries matter because
Tor MAY accept a limited number of addresses or ports. As of Tor 0.2.3.x
only the first address and the first port are used.
```
- In terms of how many `"a"`/`"or-address"` lines there may be, the spec is only correct if you pay _super close attention to the last sentence_ (this is actually the first time I've noticed it :) ).
- In terms of whether IPv4 and/or IPv6 addresses are acceptable, _the spec is currently wrong_, according to the functions `router_rebuild_descriptor()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l1811 [source]] and `router_dump_router_to_string()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l2330 [source]] in `src/or/router.c` in tor's source code.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9068Unify reachableaddresses and IPv6 settings2020-06-27T14:04:17ZNick MathewsonUnify reachableaddresses and IPv6 settingsThere's really no difference between "I can't reach IPv6" and "ClientUseIPv6 0". Let's make them redundant. Let's also add an "I can't reach IPv4" option.
See legacy/trac#6027 and legacy/trac#9067There's really no difference between "I can't reach IPv6" and "ClientUseIPv6 0". Let's make them redundant. Let's also add an "I can't reach IPv4" option.
See legacy/trac#6027 and legacy/trac#9067Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24603Update control spec to allow decorated IPv6 addresses in reachability events2020-07-28T16:16:30ZteorUpdate control spec to allow decorated IPv6 addresses in reachability eventsWhen we add IPv6 ORPort reachability checks, we want them to report decorated addresses (with brackets) to avoid ambiguity.When we add IPv6 ORPort reachability checks, we want them to report decorated addresses (with brackets) to avoid ambiguity.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6598Update dir-spec with "a" lines2020-06-27T14:05:54ZLinus Nordberglinus@torproject.orgUpdate dir-spec with "a" linesProposal 186 specifies "a" lines to go in votes and consensuses.
dir-spec needs to be updated to include "a" lines and a new voting method.Proposal 186 specifies "a" lines to go in votes and consensuses.
dir-spec needs to be updated to include "a" lines and a new voting method.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31492Update hsv3 spec for unreachable/failed single onion retries using 3 hops2021-06-23T17:24:15ZteorUpdate hsv3 spec for unreachable/failed single onion retries using 3 hopsThis ticket is the spec part of legacy/trac#23818, legacy/trac#23507, and legacy/trac#23588.This ticket is the spec part of legacy/trac#23818, legacy/trac#23507, and legacy/trac#23588.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19760Update longclaw's hard-coded IPv6 address2020-06-27T13:58:32ZteorUpdate longclaw's hard-coded IPv6 addressIn 0.2.8.1-alpha, we added longclaw's IPv6 address as
`ipv6=[2620:13:4000:8000:60:f3ff:fea1:7cff]:443`
https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n931
Now its descriptor says:
`[2620:13:4000:8000:a800:ff:fef5:2213]:443`
...In 0.2.8.1-alpha, we added longclaw's IPv6 address as
`ipv6=[2620:13:4000:8000:60:f3ff:fea1:7cff]:443`
https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n931
Now its descriptor says:
`[2620:13:4000:8000:a800:ff:fef5:2213]:443`
https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968145
Should we update this before the 0.2.8 release?Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17573Update max_dl_per_request for IPv6 address length2020-06-27T14:00:18ZteorUpdate max_dl_per_request for IPv6 address lengthmax_dl_per_request depends on the maximum length of a textual IPv4 address.
To query IPv6 directories, the NS and MICRODESC calculations need to be updated for the maximum length of a textual IPv6 address in a URL. (That is, no brackets...max_dl_per_request depends on the maximum length of a textual IPv4 address.
To query IPv6 directories, the NS and MICRODESC calculations need to be updated for the maximum length of a textual IPv6 address in a URL. (That is, no brackets.)
While we're doing that, it would be nice to add a comment with the microdescriptor length calculation as well.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29687Update prop#299 in torspec2020-06-27T13:50:43ZteorUpdate prop#299 in torspecTor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17854Use ClientIPv4 and ClientIPv6 to select a bridge address2020-06-27T13:59:57ZteorUse ClientIPv4 and ClientIPv6 to select a bridge addressIf a bridge has an IPv4 and an IPv6 address, and a tor client knows both, it should select the address family based on the values of:
* ClientUseIPv4
* ClientUseIPv6
* ClientPreferIPv6ORPort ?
(I don't think ClientPreferIPv6DirPort is r...If a bridge has an IPv4 and an IPv6 address, and a tor client knows both, it should select the address family based on the values of:
* ClientUseIPv4
* ClientUseIPv6
* ClientPreferIPv6ORPort ?
(I don't think ClientPreferIPv6DirPort is relevant here.)
This code works as-is, so I don't see any reason to change it urgently.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24677Use ping ::1 on Linux when ping6 ::1 fails2020-06-27T13:54:38ZteorUse ping ::1 on Linux when ping6 ::1 failsTurns out that some Linuxes don't have ping6, but ping ::1 works just fine.
This is a one-line change in Makefile.amTurns out that some Linuxes don't have ping6, but ping ::1 works just fine.
This is a one-line change in Makefile.amTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24546Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses2020-07-28T16:18:38ZteorUse tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addressesIn Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that s...In Tor, we try to support v6-mapped IPv4 addresses.
We should either:
* reject them unconditionally, or
* audit all uses of tor_addr_t.family to see if we should be calling tor_addr_is_v4() instead, and add a comment to the struct that says we should consider using tor_addr_is_v4() rather than comparing family.
If no relay in the consensus is currently using these addresses, then maybe we should just call them internal on authorities, relays, and clients, and remove all the code that tries to deal with them.
Discovered as part of legacy/trac#15518.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8846Useless log message when using IPv6 address on SocksPort without IPv62020-06-27T14:04:25ZTracUseless log message when using IPv6 address on SocksPort without IPv6I'm using TBB but with custom built tor executable, actually from git.tpo/debian/tor.git, and the log shows the following errors upon trying to visit an IPv6 address in TBB.
May 08 19:28:06.684 [Notice] Tor v0.2.4.11-alpha (git-f4f37a8f...I'm using TBB but with custom built tor executable, actually from git.tpo/debian/tor.git, and the log shows the following errors upon trying to visit an IPv6 address in TBB.
May 08 19:28:06.684 [Notice] Tor v0.2.4.11-alpha (git-f4f37a8fed617ffd) running on Linux with Libevent 2.0.21-stable and OpenSSL 1.0.1e.
May 08 19:28:06.684 [Notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 08 19:28:06.684 [Notice] This version is not a stable Tor release. Expect more bugs than usual.
May 08 19:28:06.686 [Notice] Read configuration file "XXXXXX/tor-browser_en-US/App/../Data/Tor/torrc".
May 08 19:28:06.692 [Notice] We were compiled with headers from version 2.0.19-stable of Libevent, but we're using a Libevent library that says it's version 2.0.21-stable.
May 08 19:28:06.692 [Notice] Opening Socks listener on 127.0.0.1:9150
May 08 19:28:06.692 [Notice] Opening Socks listener on 127.0.0.1:9050
May 08 19:28:06.692 [Notice] Opening Control listener on 127.0.0.1:9151
May 08 19:28:06.709 [Notice] Parsing GEOIP IPv4 file ./Data/Tor/geoip.
May 08 19:28:08.199 [Notice] Bootstrapped 5%: Connecting to directory server.
May 08 19:28:08.199 [Warning] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 1; recommendation warn)
May 08 19:28:08.270 [Notice] Bootstrapped 10%: Finishing handshake with directory server.
May 08 19:28:08.534 [Notice] Bootstrapped 15%: Establishing an encrypted directory connection.
May 08 19:28:08.932 [Notice] New control connection opened.
May 08 19:28:08.932 [Notice] Bootstrapped 20%: Asking for networkstatus consensus.
May 08 19:28:08.932 [Notice] Bootstrapped 25%: Loading networkstatus consensus.
May 08 19:28:10.586 [Notice] Bootstrapped 45%: Asking for relay descriptors.
May 08 19:28:10.586 [Notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 2187/3501, and can only build 27% of likely paths. (We have 65% of guards bw, 64% of midpoint bw, and 66% of exit bw.)
May 08 19:28:14.205 [Notice] We now have enough directory information to build circuits.
May 08 19:28:14.205 [Notice] Bootstrapped 80%: Connecting to the Tor network.
May 08 19:28:14.205 [Notice] Bootstrapped 90%: Establishing a Tor circuit.
May 08 19:28:14.683 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 08 19:28:14.684 [Notice] Bootstrapped 100%: Done.
May 08 19:33:48.508 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:48.792 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:50.516 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:50.517 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:51.515 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:51.516 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:52.313 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:33:52.363 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:54.314 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:57.545 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:34:00.998 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:34:01.535 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:36:28.511 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:36:50.612 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:08.202 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $A59E1E7C7EAEE083D756EE1FF6EC31CA3D8651D7~chaoscomputerclub19 at 31.172.30.2. Retrying on a new circuit.
May 08 19:37:09.088 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:34.885 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:48.819 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:57.915 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:38:35.203 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $43691853EA556C21A77E006886A5DC579855F527~sofia at 109.163.233.202. Retrying on a new circuit.
May 08 19:38:50.204 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $4F8D80A0F768A2A29856A8F26B05D35DEAA39850~wannabe at 96.47.226.19. Retrying on a new circuit.
May 08 19:39:36.202 [Notice] Tor has not observed any network activity for the past 69 seconds. Disabling circuit build timeout recording.
My torrc:
# If non-zero, try to write to disk less frequently than we would otherwise.
AvoidDiskWrites 1
# Store working data, state, keys, and caches here.
DataDirectory ./Data/Tor
GeoIPFile ./Data/Tor/geoip
# Where to send logging messages. Format is minSeverity[-maxSeverity]
# (stderr|stdout|syslog|file FILENAME).
Log notice stdout
# Bind to this address to listen to connections from SOCKS-speaking
# applications.
SocksPort 9150
ControlPort 9151
ClientPreferIPv6ORPort 1
ClientUseIPv6 1
SocksPort 127.0.0.1:9050 IPv6Traffic
I used to be able to visit IPv6 addresses from TBB up until 0.2.4.10 (if I remember correctly) using the same method (custom built tor executable).
If I start a TBB session and I don't visit any IPv6 addresses then I got no problems and no 'connection_ap_get_begincell_flags(): Bug:' messages appear in the logfile.
**Trac**:
**Username**: kargigTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23502v3 Onion Services: don't make IPv4 mandatory because one day we'll have IPv6 ...2022-06-17T14:20:27ZDavid Gouletdgoulet@torproject.orgv3 Onion Services: don't make IPv4 mandatory because one day we'll have IPv6 only relaysRight now it is not possible to have a relay that is IPv6 *only* in the public network but one day it will.
Proposal 224 makes IPv4 mandatory for link specifiers in order for a relay to extend to it. It would be wise to NOT make it mand...Right now it is not possible to have a relay that is IPv6 *only* in the public network but one day it will.
Proposal 224 makes IPv4 mandatory for link specifiers in order for a relay to extend to it. It would be wise to NOT make it mandatory and instead make it mandatory to at least have IPv4 or IPv6.https://gitlab.torproject.org/tpo/core/tor/-/issues/24181v3 Onion Services: Put IPv6 and unrecognised link specifiers in onion service...2022-06-17T14:20:39Zteorv3 Onion Services: Put IPv6 and unrecognised link specifiers in onion service EXTEND cellsProp224 says:
```
The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
```
https://gitweb.torproject.org/torspec.git/tree/p...Prop224 says:
```
The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
```
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1689
We should either remove this from the spec, or we should:
* add a similar sentence for client descriptor lspecs
* put unrecognised lspecs in descriptors in client intro EXTEND requests
* put unrecognised lspecs in INTRODUCE cells in service rend EXTEND requestshttps://gitlab.torproject.org/tpo/core/tor/-/issues/17849Warn if single-stack IPv4/IPv6 clients have very restricted guard choices2020-06-27T13:59:58ZteorWarn if single-stack IPv4/IPv6 clients have very restricted guard choicesYawning: The futueproof thing would be to warn if the selected protocol limits the number of guards to < N% probably?
Using what a dual stack host can reach as the baseline.Yawning: The futueproof thing would be to warn if the selected protocol limits the number of guards to < N% probably?
Using what a dual stack host can reach as the baseline.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21355Warn when IPv6Exits have no ipv6-policy line in their descriptor2020-07-28T02:21:36ZteorWarn when IPv6Exits have no ipv6-policy line in their descriptorThere appears to be a bug in Tor's IPv6 Exit code, where exits that have IPv6Exit set do not have an ipv6-policy line in their descriptor.
To assist in diagnosing this bug, we should log a warning message (not a bug message) containing ...There appears to be a bug in Tor's IPv6 Exit code, where exits that have IPv6Exit set do not have an ipv6-policy line in their descriptor.
To assist in diagnosing this bug, we should log a warning message (not a bug message) containing the full exit policy, when the IPv6 exit policy summary is empty, but IPv6Exit is 1 and ExitRelay is 1 or auto.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6884Warning about preferred bridge address lies2020-06-27T14:05:38ZLinus Nordberglinus@torproject.orgWarning about preferred bridge address liesWhen the ClientUseIPv6 option was added (commit e04e1a2e) the logic
for what a preferred OR port is changed. The warning about which OR
port is prefered rewrite_node_address_for_bridge() now may say
confusing things like "Will prefer IPv...When the ClientUseIPv6 option was added (commit e04e1a2e) the logic
for what a preferred OR port is changed. The warning about which OR
port is prefered rewrite_node_address_for_bridge() now may say
confusing things like "Will prefer IPv6 port" and then print an IPv4
port.
The address is correct. The address family, "IPv4" or "IPv6" may be wrong.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/26664When an exit tells a client about an IPv6-only hostname, the client should ch...2022-06-17T14:15:14ZteorWhen an exit tells a client about an IPv6-only hostname, the client should choose another IPv6 exitWhen legacy/trac#21311 and legacy/trac#21310 are finished, we need to make clients choose an IPv6 exit when an exit tells them they are connecting to an IPv6-only site
We can't choose an exit for the specific IPv6 address, because that ...When legacy/trac#21311 and legacy/trac#21310 are finished, we need to make clients choose an IPv6 exit when an exit tells them they are connecting to an IPv6-only site
We can't choose an exit for the specific IPv6 address, because that leads to tagging attacks.https://gitlab.torproject.org/tpo/core/tor/-/issues/27490When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a...2020-06-27T13:52:17ZNeel Chauhanneel@neelc.orgWhen ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at legacy/trac#17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at legacy/trac#17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomTor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.org