Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:36:05Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28966HSv3 client auth insufficiently documented (was: HiddenServiceAuthorizeClient...2020-06-13T15:36:05ZTracHSv3 client auth insufficiently documented (was: HiddenServiceAuthorizeClient incompatible)According to https://trac.torproject.org/projects/tor/ticket/20700#comment:17 this should be working.
HiddenServiceDir /var/lib/tor/keys/test
#HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1
HiddenServiceAuthorizeClient basic WUzZ...According to https://trac.torproject.org/projects/tor/ticket/20700#comment:17 this should be working.
HiddenServiceDir /var/lib/tor/keys/test
#HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1
HiddenServiceAuthorizeClient basic WUzZTg3OGQ
Dec 31 08:01:15.428 [notice] Tor 0.3.5.6-rc-dev (git-f4874765eabf1596) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1a, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Dec 31 08:01:15.428 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 31 08:01:15.428 [notice] Read configuration file "/etc/tor/torrc".
Dec 31 08:01:15.431 [warn] Hidden service option HiddenServiceAuthorizeClient is incompatible with version 3 of service in /var/lib/tor/keys/test
Dec 31 08:01:15.431 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
Dec 31 08:01:15.431 [err] Reading config failed--see warnings above.
**Trac**:
**Username**: rooTor: 0.4.2.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/28841Write tool for onion service health assessment2020-06-13T15:35:37ZGeorge KadianakisWrite tool for onion service health assessmentWe've been getting lots of reports about bad reachability of onion services (e.g. #28730) and in particular the v3 ones.
We need a tool that we can use to evaluate and monitor the health of onion services. We should use it to verify how...We've been getting lots of reports about bad reachability of onion services (e.g. #28730) and in particular the v3 ones.
We need a tool that we can use to evaluate and monitor the health of onion services. We should use it to verify how reachable and stable onions are, and also as a benchmark for how their stability changes over time.
A relevant ticket here is #13209 which we can leverage in the future.
One way to write such a tool is to provide it with an onion service, and the tool fetches its desc from every HSDir, then introduces itself to all the intro points, and make sure that rendezvous can occur. Then it monitors this over time to find issues with reachability.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28005Officially support onions in HTTPS-Everywhere2022-09-01T22:43:24ZGeorge KadianakisOfficially support onions in HTTPS-EverywhereThe plan:
A major UX issue for onion services is their huge addresses. We want to fix this issue because an address with 56 random characters confuses people, it makes it harder to pass the address around, and it also makes it much hard...The plan:
A major UX issue for onion services is their huge addresses. We want to fix this issue because an address with 56 random characters confuses people, it makes it harder to pass the address around, and it also makes it much harder to verify it.
There is a field of literature called "secure name systems" but none of the candidates are good enough for us right now. Hence, we present a hotfix that might offer a situational relief for users for the medium-term future, until we come up with something better, or while we experiment with more solutions. I suggest we keep this ticket focused to this idea, instead of debating why this and not that since we've already been doing this for far too long.
The plan is to use the HTTPS-Everywhere extension that we already have in Tor Browser, and encourage people to write their own rulesets for onions. We are talking about community-maintained rulesets and nothing that is officially maintained by The Tor Project or by HTTPS-Everywhere. This ticket is about making it easier for people to create, import and use this rulesets. We are talking about UI/UX improvements, writing blog posts and doing Q&A.
Here are some example of community rulesets we can imagine:
* The SecureDrop ruleset: where securedrop makes a ruleset with their whole directory. People can download that to quickly visit securedrop destinations, by going to securedrop-nyt.tor.onion .
* The Torproject ruleset: where torproject makes a ruleset with all their onions. We developers can use that to quickly visit Tor sites over onion, by going to tor-trac.tor.onion instead of remembering the onion.
* The Bitcoin ruleset: where a "trusted" bitcoin entity publishes a ruleset with various cryptocurrency-related rules that allow people to quickly visit them.
This approach has both positives and negatives (I assure you this is the case with every "secure naming" project out there):
* Positives: Good security if the ruleset is taken from a trusted source. No state keeping. Reachable engineering effort. No global names, hence no fear of name squatting. Easy to understand tradeoffs.
* Negatives: Terrible security if the ruleset is evil. No global names: If you want people to use your shorten onion name, you need to persuade them to use your ruleset.
Here are some HTTPS-Everywhere issues we need to solve based on my Mexico notes:
* Be able to stop update channels per-channel.
* Need good UI to easily look and understand rules.
* Need to implement file extension to install ruleset with one-click from web button.
Here are some issues we need to think about:
* We need good user text to make sure that people don't shoot themselves in the foot too often by installing bad rulesets and whatnot (they already do it daily when they open onions from "search enginers" or reddit).
* Which tld to use? If we use .tor we open ourselves to DNS leaks in normal browsers. If we use .tor.onion that might be confusing to people.
* Are there any issues with SSL?
More resources:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/OnionV3ux
https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/HTTPSEverywhereNotes
https://blog.torproject.org/cooking-onions-names-your-onionshttps://gitlab.torproject.org/legacy/trac/-/issues/27680Explain how to use auth cookie for onion services2020-06-13T15:31:18ZtraumschuleExplain how to use auth cookie for onion serviceshttps://www.torproject.org/docs/tor-manual.html.en#HidServAuth
https://www.torproject.org/docs/tor-onion-service.html.en
#19757https://www.torproject.org/docs/tor-manual.html.en#HidServAuth
https://www.torproject.org/docs/tor-onion-service.html.en
#19757Tor: 0.4.1.x-finaltraumschuletraumschulehttps://gitlab.torproject.org/legacy/trac/-/issues/27636.onion indicator for non-self-signed but non-trusted sites2020-06-16T00:51:02ZTrac.onion indicator for non-self-signed but non-trusted sitesWith #23247 (really great addition btw!) implemented, I tried to visit https://www.ysp4gfuhnmj6b4mb.onion/
This page uses a custom CA, which is not trusted by tor browser (or any other browser by default) and is reachable through .onion...With #23247 (really great addition btw!) implemented, I tried to visit https://www.ysp4gfuhnmj6b4mb.onion/
This page uses a custom CA, which is not trusted by tor browser (or any other browser by default) and is reachable through .onion with a correct CN in the certificate.
Now currently with TB 8.0 I get a "Your connection is not secure" (SEC_ERROR_UNKNOWN_ISSUER), but at the same time a green onion+padlock indicator. This is quite confusing.
Reading through #23247 I am not sure what the intended behavior would be. But self-signed certificates are trusted when accessed through .onion. From that point of view it does not make much sense to handle certificates signed by untrusted CAs differently.
My expectation would be to not see the untrusted issuer warning and get the green onion *without* padlock indicator.
**Trac**:
**Username**: o--richardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/27590Display .onion alt-svc route in the circuit display2020-06-16T00:50:46ZTracDisplay .onion alt-svc route in the circuit displayNow that #24553 has re-enabled alt-svc, the Circuit Display should probably indicate when the connection was made via an .onion alt-svc. Currently it doesn't.
Feel free to use this for testing: https://perfectoid.space/test.php
When the...Now that #24553 has re-enabled alt-svc, the Circuit Display should probably indicate when the connection was made via an .onion alt-svc. Currently it doesn't.
Feel free to use this for testing: https://perfectoid.space/test.php
When the page turns green, click on the green https lock to see the circuit.
**Trac**:
**Username**: mahrudhttps://gitlab.torproject.org/legacy/trac/-/issues/27502Prioritize .onion hosts in AltSvc?2020-06-16T00:50:15ZArthur EdelsteinPrioritize .onion hosts in AltSvc?We now support AltSvc and Mahrud suggested we might want to prioritize .onion AltSvc hosts in Tor Browser. It's an interesting idea and I would need to think about it more to know if it's desirable. Mahrud also pointed out a web page tha...We now support AltSvc and Mahrud suggested we might want to prioritize .onion AltSvc hosts in Tor Browser. It's an interesting idea and I would need to think about it more to know if it's desirable. Mahrud also pointed out a web page that demonstrates AltSvc over .onion:
https://perfectoid.space/test.php
Refresh several times and it will turn green when .onion is being used.Matthew FinkelMatthew Finkelhttps://gitlab.torproject.org/legacy/trac/-/issues/27471HS intermittently fails: Non-fatal assertion failed in send_introduce12020-06-13T15:36:10ZTracHS intermittently fails: Non-fatal assertion failed in send_introduce1When running 0.3.4.7-rc on Buster from deb.tpo
```
[WARN] Bug: /usr/bin/tor(_start+0x2a) [0x55edbc918eea]
[WARN] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fd267a49b17]
[WARN] Bug: /usr/bin/tor(main+0x1...When running 0.3.4.7-rc on Buster from deb.tpo
```
[WARN] Bug: /usr/bin/tor(_start+0x2a) [0x55edbc918eea]
[WARN] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fd267a49b17]
[WARN] Bug: /usr/bin/tor(main+0x19) [0x55edbc918e99]
[WARN] Bug: /usr/bin/tor(tor_main+0x3a) [0x55edbc9190ea]
[WARN] Bug: /usr/bin/tor(tor_run_main+0x1005) [0x55edbc921155]
[WARN] Bug: /usr/bin/tor(do_main_loop+0x205) [0x55edbc91ea85]
[WARN] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7fd26873f537]
[WARN] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7fd26873e9ba]
[WARN] Bug: /usr/bin/tor(+0x5271e) [0x55edbc91c71e]
[WARN] Bug: /usr/bin/tor(connection_handle_read+0xa73) [0x55edbc9decf3]
[WARN] Bug: /usr/bin/tor(+0x11e016) [0x55edbc9e8016]
[WARN] Bug: /usr/bin/tor(channel_tls_handle_cell+0x4db) [0x55edbc9a3e4b]
[WARN] Bug: /usr/bin/tor(command_process_cell+0x318) [0x55edbc9c2368]
[WARN] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x2c4) [0x55edbc9448f4]
[WARN] Bug: /usr/bin/tor(+0x788bb) [0x55edbc9428bb]
[WARN] Bug: /usr/bin/tor(rend_process_relay_cell+0x293) [0x55edbc94b9b3]
[WARN] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x79) [0x55edbca31a89]
[WARN] Bug: /usr/bin/tor(connection_ap_attach_pending+0x178) [0x55edbc9e1e58]
[WARN] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x3bd) [0x55edbc9c0f3d]
[WARN] Bug: /usr/bin/tor(hs_client_send_introduce1+0x232) [0x55edbca31382]
[WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55edbca6e499]
[WARN] Bug: /usr/bin/tor(log_backtrace+0x43) [0x55edbca537a3]
[WARN] Bug: Non-fatal assertion !(ip == NULL) failed in send_introduce1 at ../src/or/hs_client.c:559. Stack trace:
[WARN] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:559: send_introduce1: Non-fatal assertion !(ip == NULL) failed.
```
**Trac**:
**Username**: tgragnatoTor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/27251Add single-onion-v23-ipv6-md to make test-network-all2020-06-13T15:29:56ZteorAdd single-onion-v23-ipv6-md to make test-network-allWhen IPv6 single onion services work, we should add the single-onion-v23-ipv6-md to TEST_CHUTNEY_FLAVORS_IPV6in src/test/include.am.
We can also remove single-onion-ipv6-md, because it's redundant.When IPv6 single onion services work, we should add the single-onion-v23-ipv6-md to TEST_CHUTNEY_FLAVORS_IPV6in src/test/include.am.
We can also remove single-onion-ipv6-md, because it's redundant.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/26806Check if Tor clients sometimes send duplicate cells on rendezvous circuits: P...2020-06-13T15:28:06Zs7rCheck if Tor clients sometimes send duplicate cells on rendezvous circuits: Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seenAs my v3 onion service is getting more and more popular, I started to get:
```
[warn] Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen 32 seconds ago. Dropping cell.
```
I am inclined to think that th...As my v3 onion service is getting more and more popular, I started to get:
```
[warn] Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen 32 seconds ago. Dropping cell.
```
I am inclined to think that this is more like a bug in Tor, maybe due to a race condition, rather than a replay attack.
I also think this is what causes #15618 - dgoulet confirmed that the warning can be reproduced every time a second `ESTABLISH_RENDEZVOUS` is sent over the same circuit.
This can probably go away if we fix #21084. I am not sure if that should be a parent ticket here or not, please change if you feel like it. I think I still have yawning's tool and notes about how to reproduce #21084.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26768Support onionbalance in HSv32020-06-13T15:27:55ZGeorge KadianakisSupport onionbalance in HSv3We are implementing onionbalance in v3! This is the master ticket.
[Description changed to not confuse people with the old design.]We are implementing onionbalance in v3! This is the master ticket.
[Description changed to not confuse people with the old design.]Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/25882clients not detecting stale onion service introduction points2020-06-13T15:48:37Zcypherpunksclients not detecting stale onion service introduction pointsTor version 0.3.2.10 running on Debian stretch;
The Tor client runs continuously over many days. Periodically (daily in this case), an HTTP client reaches out to the same v2 onion service via Tor. Normally, this works correctly.
Howe...Tor version 0.3.2.10 running on Debian stretch;
The Tor client runs continuously over many days. Periodically (daily in this case), an HTTP client reaches out to the same v2 onion service via Tor. Normally, this works correctly.
However, sometimes (no more than about 2/5 of the days), the HTTP client will fail to connect properly to the onion service, and its TCP connection will simply time out. Restarting Tor almost always solves this problem, although automating a reactive Tor restart is undesirable, particularly when doing so closes all of the circuits of all other client applications using the same Tor.
Looking closely, we observe that in such cases the Tor client is not able to complete a rendezvous with the onion service. Specifically, the Tor client reaches out to the same intro point many times in rapid succession, without ever managing to establish a connection. I surmise that a workaround might entail asking Tor to clear its cached onion service descriptor for this particular v2 service. However, the code to handle client connections to onion services in `hs_client.c` intends to handle introduction point failures, so we should really determine why the many attempts to connect to the same introduction point are not logged as a failure that would ultimately lead to fetching the server descriptor again.
My logs show that during a typical onion service request, my Tor attempted to connect to the same introduction point, 176.36.20.10, a total of 47 times in the 112-second interval between 06:52:06 and 06:53:58 UTC.
```
Apr 21 06:53:55.000 [debug] relay_send_command_from_edge_(): delivering 33 cell forward.
Apr 21 06:53:55.000 [debug] relay_send_command_from_edge_(): Sending a RELAY_EARLY cell; 4 remaining.
Apr 21 06:53:55.000 [debug] circuit_package_relay_cell(): encrypting a layer of the relay cell.
Apr 21 06:53:55.000 [debug] circuit_package_relay_cell(): encrypting a layer of the relay cell.
Apr 21 06:53:55.000 [debug] circuit_package_relay_cell(): encrypting a layer of the relay cell.
Apr 21 06:53:55.000 [debug] append_cell_to_circuit_queue(): Made a circuit active.
Apr 21 06:53:55.000 [debug] scheduler_channel_has_waiting_cells(): Channel 64 at 0x1c12450 went from waiting_for_cells to pending
Apr 21 06:53:55.000 [info] circuit_get_best(): There is an intro circuit being created right now, but it has already taken quite a while. Starting one in parallel.
Apr 21 06:53:55.000 [info] circuit_get_open_circ_or_launch(): Chose $04D962C6155BFC3705DC3 8699D4E6B3CE1524AE7~$04D962C6155BFC3705 at 176.36.20.10 as intro point for '[scrubbed]'.
Apr 21 06:53:55.000 [debug] circuit_find_to_cannibalize(): Hunting for a circ to cannibalize: purpose 6, uptime 0, capacity 1, internal 1
Apr 21 06:53:55.000 [info] circuit_launch_by_extend_info(): Cannibalizing circ 3202873042 (id: 457) for purpose 6 (Hidden service client: Connecting to intro point)
Apr 21 06:53:55.000 [debug] circuit_change_purpose(): changing purpose of origin circ 457 from "General-purpose client" (5) to "Hidden service client: Connecting to intro point" (6)
Apr 21 06:53:55.000 [debug] circuit_send_intermediate_onion_skin(): starting to send subsequent skin.
Apr 21 06:53:55.000 [info] circuit_send_intermediate_onion_skin(): Sending extend relay cell.
Apr 21 06:53:55.000 [debug] relay_send_command_from_edge_(): delivering 6 cell forward.
Apr 21 06:53:55.000 [debug] relay_send_command_from_edge_(): Sending a RELAY_EARLY cell; 4 remaining.
Apr 21 06:53:55.000 [debug] circuit_package_relay_cell(): encrypting a layer of the relay cell.
Apr 21 06:53:55.000 [debug] circuit_package_relay_cell(): encrypting a layer of the relay cell.
Apr 21 06:53:55.000 [debug] circuit_package_relay_cell(): encrypting a layer of the relay cell.
Apr 21 06:53:55.000 [debug] append_cell_to_circuit_queue(): Made a circuit active.
Apr 21 06:53:55.000 [info] rep_hist_note_used_internal(): New port prediction added. Will continue predictive circ building for 2522 more seconds.
Apr 21 06:53:55.000 [info] connection_ap_handshake_attach_circuit(): Intro 3202873042 (id: 457) and rend circuit 2500882674 (id: 483) circuits are not both ready. Stalling conn. (109 sec old)
Apr 21 06:53:55.000 [info] circuit_predict_and_launch_new(): Have 12 clean circs (0 uptime-internal, 12 internal), need another hidden service circ.
```
Note that the same introduction point is chosen each time, and Tor never decides that the introduction point is invalid. Suggest that this may lead Tor to not request a new onion service descriptor. (It is not clear to me that the "interesting" AS in which the introduction point resides (39608, in the United Arab Emirates) is important in this case.) Suggest that the problem may be a matter of abstraction layers, e.g. Tor invalidates introduction points at a higher layer but retries at a lower layer such that the retries are opaque to the invalidation process.
This problem should be considered important, as it may lead to long-lived Tor clients becoming unable to connect to long-lived onion services, not to mention Type I errors in the systematic assessment of whether a given onion service is down.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25568hs: Lookup failure cache when introducing to an intro point2020-06-13T15:23:25ZDavid Gouletdgoulet@torproject.orghs: Lookup failure cache when introducing to an intro pointIt turns out that if a descriptor contains 10 times the same intro point, and that the first introduction attempt fails, we'll try to connect to the same failing intro point again for all subsequent remaining intro points.
The intro poi...It turns out that if a descriptor contains 10 times the same intro point, and that the first introduction attempt fails, we'll try to connect to the same failing intro point again for all subsequent remaining intro points.
The intro point failure cache was introduced to avoid such a situation but it is only used between two descriptors that is if an intro point failed from the first descriptor and that intro point is still present in the second descriptor fetched, we ignore it.
However, this situation is about the same intro point in the same descriptor. In normal circumstances, this can't happen but it is still allowed by the protocol.
One issue with this is that a malicious service would induce many circuits out of the client than necessary. This can be used, theoretically, for a client guard discovery attack.
This affects both v2 and v3.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24964dos: Block single hop client at the HSDir2020-06-13T15:46:21ZDavid Gouletdgoulet@torproject.orgdos: Block single hop client at the HSDirThis is so we remove load from spammy tor2web clients at the HSDir level.
Opened after discussion in #24902.This is so we remove load from spammy tor2web clients at the HSDir level.
Opened after discussion in #24902.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24963dos: Block single hop clients at the intro point2020-06-13T15:20:54ZDavid Gouletdgoulet@torproject.orgdos: Block single hop clients at the intro pointThis is so we remove load from spammy single hop clients at the Intro point.
Opened after discussion in #24902.
Lets consider this also as a possible backport.This is so we remove load from spammy single hop clients at the Intro point.
Opened after discussion in #24902.
Lets consider this also as a possible backport.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24962Single hop onion service denial of service issues2020-06-13T15:45:38ZDavid Gouletdgoulet@torproject.orgSingle hop onion service denial of service issuesThis is a parent ticket for all single hop anti-DoS mitigation we want to put in Tor. Not only that but it should be seen as "any client single hop" hidden service requests rather than tor2web specific.
Child tickets are really the meat...This is a parent ticket for all single hop anti-DoS mitigation we want to put in Tor. Not only that but it should be seen as "any client single hop" hidden service requests rather than tor2web specific.
Child tickets are really the meat of the work so anything related to this topic should have a child ticket and this parent ticket should not be used for discussions.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23818Make v2 and v3 single onion services retry all failed intro and rend connecti...2020-06-13T15:44:30ZteorMake v2 and v3 single onion services retry all failed intro and rend connections with a 3-hop pathThis makes a single onion service connect via an entry that it can reach when connections fail.This makes a single onion service connect via an entry that it can reach when connections fail.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23588Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_f...2020-06-13T15:44:30ZteorWrite fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()Currently, the address choice logic is:
* if we have an IPv6 address and can reach the ls IPv6 address, and prefer IPv6, use it
* if we have an IPv4 address and can reach the ls IPv4 address, use it
But it needs to be:
* if we have both...Currently, the address choice logic is:
* if we have an IPv6 address and can reach the ls IPv6 address, and prefer IPv6, use it
* if we have an IPv4 address and can reach the ls IPv4 address, use it
But it needs to be:
* if we have both addresses and can reach both, then use whatever we prefer
* if we have one address and can reach it, use it
This doesn't matter until clients put IPv6 addresses in the link specifier.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23545UX improvement: Tor Browser should handle bogus HSv3 addresses2020-06-16T01:10:51ZGeorge KadianakisUX improvement: Tor Browser should handle bogus HSv3 addressesHS v3 addresses are big but also contain a checksum. This means that Tor Browser could catch mistyped addresses and warn the user.
With current master and current Tor browser, if you mistype an hsv3 address you go to the _Unable to conn...HS v3 addresses are big but also contain a checksum. This means that Tor Browser could catch mistyped addresses and warn the user.
With current master and current Tor browser, if you mistype an hsv3 address you go to the _Unable to connect_ page:
```
Unable to connect
Firefox can’t establish a connection to the server at 4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqeflock.onion.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer’s network connection.
If your computer or network is protected by a firewall or proxy, make sure that Tor Browser is permitted to access the Web.
```
In the logs you can see a parsing error:
```
[warn] Invalid onion hostname [scrubbed]; rejecting
```
which is a bit generic.
I wonder what's the best way to offer better UX here. How should the user be warned?
Also how should we implement this? Should the Browser do the checksum check itself? Or should Tor do the checksum check and inform Tor Browser somehow?
How to do this best?Tor: unspecifiedKathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/23507Handle unreachable addresses on v3 single onion services by using a 3 hop path2020-06-13T15:44:30ZteorHandle unreachable addresses on v3 single onion services by using a 3 hop pathHere is how we make IPv6 (and other unreachable addresses) work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop...Here is how we make IPv6 (and other unreachable addresses) work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop224 spec.
Here are the steps:
0. The service chooses and connects to the intro point (possibly using a 3-hop path if it is a single onion service and can't reach it directly)
1. The service always puts IPv4 and IPv6 in its descriptor link specifiers (if they are available in directory documents)
2. If the link specifier has a reachable address, and the service is not a single onion service, a Tor2web client (currently v2 only) can use it to make a direct connection to the intro point
3. Otherwise, the client connects over a 3-hop path via one of its reachable entry nodes
The process for client rendezvous is similar, but if the client knows that the service is a single onion service, it *must* connect to the rend point using a 3-hop path. (Again, this only matters for Tor2web, which is v2 only).Tor: 0.4.2.x-finalteorteor