Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:12:26Zhttps://gitlab.torproject.org/legacy/trac/-/issues/3733Tor should abandon rendezvous circuits that cause a client request to time out2020-06-13T14:12:26ZRobert RansomTor should abandon rendezvous circuits that cause a client request to time out```
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice...```
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:10.634 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:30.680 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
```
All of these streams had been attached to the same rendezvous circuit.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14389little-t-tor: Provide support for better TBB UI of hidden service client auth...2020-06-16T01:02:43ZGeorge Kadianakislittle-t-tor: Provide support for better TBB UI of hidden service client authorization**This is the network-team-side of ticket #30237.
**
The current hidden service spec allows clients to authenticate themselves using auth-cookies. The future proposal 224 will allow clients to authenticate using username/password or pubk...**This is the network-team-side of ticket #30237.
**
The current hidden service spec allows clients to authenticate themselves using auth-cookies. The future proposal 224 will allow clients to authenticate using username/password or pubkey.
Currently users have to edit their torrc and add HidServAuth lines for the hidden services that require authorization. In the future, it would be nicer if TBB had an interface for users to type in their authorization credentials.
Tor knows whether an HS needs authorization, because the intro list is encrypted. Tor would have to somehow transfer this knowledge to TBB, so that the browser can present a nice UI that the user can fill on the go.
Furthermore, with the future username/password authorization and this UI improvement, it won't be necessary for people to write on their torrc which hidden services they visit and what's their auth-cookie.
This is a ticket about finding out what mods need to happen in little-t-tor, and coordinating the development of this feature.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15516Consider rate-limiting INTRODUCE2 cells when under load2022-03-22T13:12:44ZJohn BrooksConsider rate-limiting INTRODUCE2 cells when under loadIn #15463, we're seeing an effective denial of service against a HS with a flood of introductions. The service falls apart trying to build rendezvous circuits, resulting in 100% CPU usage, many failed circuits, and impact on the guard.
...In #15463, we're seeing an effective denial of service against a HS with a flood of introductions. The service falls apart trying to build rendezvous circuits, resulting in 100% CPU usage, many failed circuits, and impact on the guard.
We should consider dropping INTRODUCE2 cells when the HS is under too much load to build rendezvous circuits successfully. It's much better if the HS response in this situation is predictable, instead of hammering at the guard until something falls down.
One option is to add a HSMaxConnectionRate(?) option defining the number of INTRODUCE2 we would accept per 10(?) minutes, maybe with some bursting behavior. It's unclear what a useful default value would be.
We could try to use a heuristic based on when rend circuits start failing, but it's not obvious to me how that would work.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/19251TorBrowser might want to have an error page specific to when .onion links fail2020-06-16T01:13:05ZcypherpunksTorBrowser might want to have an error page specific to when .onion links failWhen a webpage fails to load, it can be due to any number of factors. But when that page is served by an onion service, some of those factors have greater implications for security.
It would be cool to know if the failure is related to ...When a webpage fails to load, it can be due to any number of factors. But when that page is served by an onion service, some of those factors have greater implications for security.
It would be cool to know if the failure is related to a malfunction in the local Tor instance, or due to nonlocal failures. If TBB can determine this, adding something to TBB to create .onion specific error messages with greater detail would be helpful.Kathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/19757Make a menu to add onion and auth-cookie to TB2020-06-16T01:11:28ZNima FatemiMake a menu to add onion and auth-cookie to TBCurrently it's very difficult to add an onion address and auth cookie to Tor Browser.
It would be nice to have an option in torbutton menu where you can set `HidServAuth` and optionally `MapAddress`, instead of having to edit your TB t...Currently it's very difficult to add an onion address and auth cookie to Tor Browser.
It would be nice to have an option in torbutton menu where you can set `HidServAuth` and optionally `MapAddress`, instead of having to edit your TB torrc file.Kathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/21952Onion-location: increasing the use of onion services through automatic redire...2021-03-22T16:56:26ZLinda LeeOnion-location: increasing the use of onion services through automatic redirects and aliasing= Background =
People can't remember, or type in onion sites very easily. We should try to fix this somehow.
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they ...= Background =
People can't remember, or type in onion sites very easily. We should try to fix this somehow.
ilf is experimenting with automatically redirecting Tor users to .onion versions of websites that they visit (because they want more people to visit onion sites and they will do so if it is painless to them). But when users were redirected automatically to an onion site, they freaked out about it because they didn't know what happened, didn't know what onion sites were, and the "https" was dropped.
asn and dgoulet also were trying to find a solution to make onion sites more accessible to use. Specifically, onion addresses are quite long and random-ish, making them hard to remember and hard to type. There were many solutions discussed casually to try and resolve this, but none stood out as a clear winner.
= Discussion =
I like the idea of redirecting users to .onion sites automatically when they type in the websites non-onion address. This way, users don't need to remember anything else, need to type in anything long, or really even know what onion sites are.
My suggestion is to follow the https design pattern, and create a similar indicator for .onion sites.
![onion-address-idea.png,600px](uploads/onion-address-idea.png,600px)
The proposed solution would be this: when a user types in a website (pad.riseup.net), they would automatically be redirected to the onion site. When this happens, there would be an onion icon next to the address bar (replacing the https lock icon if there is one, or just being there an https lock icon would be if redirection from an http website), similar to that of the https lock icon. The address in the address bar can turned a different color or indicated in some way that this is an alias for the onion site.
From my observation, people don't mind automatically being redirected to https sites from http sites, but freak out when redirected from an http/https site to an onion site. I don't think that this is because people know what https is and find the idea comforting (although this can help). I speculate that they don't mind because they don't notice, and the reason why users freaked out at the redirect to onion sites is that they saw the website address visibly change in the address bar.
Also--
If we want to show users the address of the onion site, we can additionally have a feature to reveal the onion site when the user clicks in the address bar.
![onion-address-secondary-idea.png,600px](uploads/onion-address-secondary-idea.png,600px)
I don't know how I feel about this, since it may just be confusing, and just shock the user later. Users don't know that pad.riseup.net resolves to some numerical IP address, and that isn't displayed to users. So there could be an argument made for just indicating that the address is an alisas and not ever showing the .onion address, either. This will confuse way less of the general population.
= Considerations =
* how should the redirect behavior work?
* how can we implement this without tracking?
* should we allow users to turn off this redirecting behavior?
* should we hide the .onion address from the users more so than the proposal above?Alex CatarineuAlex Catarineuhttps://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-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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/28970tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_ke...2020-06-13T15:42:46ZTractor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertionIf this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received rel...If this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jan 01 05:31:32.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jan 01 05:31:32.000 [notice] Read configuration file "/etc/tor/torrc".
Jan 01 05:31:32.000 [notice] Tor 0.3.4.9 (git-074ca2e0054fded1) opening log file.
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at ../src/or/hs_client.c:624. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_circuit_has_opened+0x2ca) [0x56345ce8027a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_send_next_onion_skin+0x372) [0x56345cdfd192] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x78fc3) [0x56345cd92fc3] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:443: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/or/hs_client.c:443. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_send_introduce1+0x352) [0x56345ce7fda2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x33c) [0x56345ce1126c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_attach_pending+0x1a0) [0x56345ce31cb0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x79) [0x56345ce803c9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x28b) [0x56345cd9c2cb] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x791f7) [0x56345cd931f7] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
```
Tor on Linux. Is it related to #27471 or #19926?
**Trac**:
**Username**: torcrashTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29034circuit: Cleanup an HS circuit when it is being re-purposed2020-06-13T15:42:10ZDavid Gouletdgoulet@torproject.orgcircuit: Cleanup an HS circuit when it is being re-purposedMike found out that when an IP/RP circuit fails to build in the right amount of time (for instance through `circuit_expire_building()`), it is re-purposed to become a measurement circuit.
The issue is that those HS circuits are set in t...Mike found out that when an IP/RP circuit fails to build in the right amount of time (for instance through `circuit_expire_building()`), it is re-purposed to become a measurement circuit.
The issue is that those HS circuits are set in the HS circuitmap and have an `hs_ident` or `rend_data` set to them that should really not linger in the circuit object if the circuit is not an HS one anymore.
Offenders: `circuit_build_times_mark_circ_as_measurement_only()` and `pathbias_send_usable_probe()`.
Solution:
`circuit_change_purpose()` is probably the right place to make a callback within the HS subsystem specific to cleaning up a circuit for a purpose change. I think we need a new function that specifically does that and not use `hs_circ_cleanup()` since it won't remove the ident.
Lingering circuits in the HS circuitmap is bad and this bug could probably explain some of the issues we had with clients unable to establish connections because the IP auth key wouldn't match the one in the circuit ident.
I strongly believe this should be backported up to 0.3.5 at the very least.Tor: 0.3.5.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/29237Restore IPv6 intro points in the HS client tests2020-06-13T15:37:37ZteorRestore IPv6 intro points in the HS client testsIn #23576, I removed an IPv6-only intro point from the HS client tests. We should put it back in.In #23576, I removed an IPv6-only intro point from the HS client tests. We should put it back in.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29338restore HiddenServiceAuthorizeClient in v32020-06-13T15:37:55ZTracrestore HiddenServiceAuthorizeClient in v3According to the manual, for v3 hidden services, if the contents of <HiddenServiceDir>/authorized_clients/ cannot be loaded, then the Hidden Service is enabled and is accessible to anyone with the onion address. This is a security hole....According to the manual, for v3 hidden services, if the contents of <HiddenServiceDir>/authorized_clients/ cannot be loaded, then the Hidden Service is enabled and is accessible to anyone with the onion address. This is a security hole. It opens the possibility that the user intended for the service to require authorization, but due to files being moved or deleted or inaccessible or other file system problem, the hidden service incorrectly becomes accessible to anyone.
Please restore the configuration option HiddenServiceAuthorizeClient for v3 services. If it is set to "basic", then authentication should be required for the service regardless of whether <HiddenServiceDir>/authorized_clients/ can be read, or alternately, if the authorized users cannot be read, tor should not start up or should not enable the hidden service.
**Trac**:
**Username**: AlanTor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/296072019 Q1: Denial of service on v2 and v3 onion service2022-03-22T13:12:44ZTrac2019 Q1: Denial of service on v2 and v3 onion serviceDear tor team,
We have setup a discussion board, on the tor network.
And there is someone that is exploiting within our servers, by taking it down it every time and the forums will respond with "Server not found".
We are pretty sure this...Dear tor team,
We have setup a discussion board, on the tor network.
And there is someone that is exploiting within our servers, by taking it down it every time and the forums will respond with "Server not found".
We are pretty sure this problem is on the side of the TOR browser, is there anything we could do to sort this?
With many thanks for taking time into reading this.
**Trac**:
**Username**: pidginTor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29669hs: ADD_ONION with NEW:BEST is still pinned on v22020-06-13T15:39:01ZDavid Gouletdgoulet@torproject.orghs: ADD_ONION with NEW:BEST is still pinned on v2Even though the control spec says:
```
(The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
value. Since 0.3.5.1-alpha, it is 3. For Tor versions before 0.3.5.1-alpha,
default HiddenServiceVersion is 2.)
```
...Even though the control spec says:
```
(The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
value. Since 0.3.5.1-alpha, it is 3. For Tor versions before 0.3.5.1-alpha,
default HiddenServiceVersion is 2.)
```
... in control.c, the `ADD_ONION` command has this condition that basically pins the `NEW:BEST` to v2:
```
if (!strcasecmp(key_type_rsa1024, key_blob) ||
!strcasecmp(key_type_best, key_blob)) {
/* "RSA1024", RSA 1024 bit, also currently "BEST" by default. */
```
Not good! `NEW:BEST` should obey the default version, not something hardcoded like so. This will need a spec update to mention the correct tor version.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/29995Objective 1, Activity 1.1: Make v3 the default on Core Tor stable2020-06-13T15:47:38ZPili GuerraObjective 1, Activity 1.1: Make v3 the default on Core Tor stableThis is the parent ticket to hold any tickets under this activity, including:
- Making onion services v3 the default option on Core Tor
- Implementing a set of fixes to issues we have documented at our issue tracker, in order to:
- R...This is the parent ticket to hold any tickets under this activity, including:
- Making onion services v3 the default option on Core Tor
- Implementing a set of fixes to issues we have documented at our issue tracker, in order to:
- Reduce onion service exposure to malicious relays
- Create faster and more reliable client connections
- Create more reliable client connections for bridge usersTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29998Objective 1, Activity 1.2: Adopt OnionBalance features into onion services v32020-06-13T15:40:10ZPili GuerraObjective 1, Activity 1.2: Adopt OnionBalance features into onion services v3This is the parent ticket to hold any tickets under this activity, including:
- Improving scalability of onion services by adopting OnionBalance features into onion services v3This is the parent ticket to hold any tickets under this activity, including:
- Improving scalability of onion services by adopting OnionBalance features into onion services v3Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29999Objective 1, Activity 2: Denial of service defences2020-06-13T15:40:11ZPili GuerraObjective 1, Activity 2: Denial of service defencesThis is the parent ticket to hold any tickets under this activity, including:
- Reducing the amount of circuits that they build over time on the Tor network
- Providing more ways for onion service administrators to control the influx of ...This is the parent ticket to hold any tickets under this activity, including:
- Reducing the amount of circuits that they build over time on the Tor network
- Providing more ways for onion service administrators to control the influx of incoming users in heavy traffic scenarios.
- Improving our defense mechanisms by:
- Decreasing onion service load on the Tor network, by slowing down Tor circuit creation on startup.
- Optimizing relevant onion service functions that are called multiple times therefore taking a lot of the CPU.
- Making it harder for adversaries to force services to rotate their introduction points.
- Writing a Tor software change proposal for a “rendezvous approver” API that can be useful for:
1. Rate limiting; allow at most N unauthenticated clients over a set time period
2. Extra-conservative logic like "stop accepting connections during potential guard discovery"
3. Limiting capacity to control server load; only allow N simultaneous clients.
4. Protocol-tuned rules for things like Ricochet
5. More advanced pre-rendezvous authorization
6. Load-balancing across multiple servers running Tor onion services
- Closing client circuit once the INTRO1/ACK dance has been completed, decreasing load on the Tor network.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30000Objective 2, Activity 1: Integrating client-side authorization to onion servi...2020-06-16T01:02:07ZPili GuerraObjective 2, Activity 1: Integrating client-side authorization to onion services v3This is the parent ticket to hold any tickets under this activity, including:
- Rebuilding the client experience on the Tor Browser.
- Improving the end to end experience for onion service operators and their users.This is the parent ticket to hold any tickets under this activity, including:
- Rebuilding the client experience on the Tor Browser.
- Improving the end to end experience for onion service operators and their users.https://gitlab.torproject.org/legacy/trac/-/issues/30019Write content for the onion services section in the community portal2020-06-13T17:27:54ZGeorge KadianakisWrite content for the onion services section in the community portalHere is a ticket to trac this item.Here is a ticket to trac this item.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/30022Objective 2, Activity 2: Notify users about typo errors when entering .onion ...2020-06-16T01:02:09ZPili GuerraObjective 2, Activity 2: Notify users about typo errors when entering .onion addressesThis is the parent ticket to hold any tickets under this activity, including:
- Using the address format of onion services v3 that allows us to detect typos.
- Experimenting with the optimal user experience for this error case, e.g. off...This is the parent ticket to hold any tickets under this activity, including:
- Using the address format of onion services v3 that allows us to detect typos.
- Experimenting with the optimal user experience for this error case, e.g. offering a retry-button after explaining what went wrong.
- Implementing a special error page that tells the user the problem is a typo in the address.https://gitlab.torproject.org/legacy/trac/-/issues/30024Objective 2, Activity 3: Notify users if a current website they are visiting ...2020-06-16T01:02:11ZPili GuerraObjective 2, Activity 3: Notify users if a current website they are visiting on Tor Browser has an onion service versionThis is the parent ticket to hold any tickets under this activity, including:
- Investigate the ideal browser user experience for when such a redirection takes place, to minimize user confusion.
- Build the code necessary to optimally s...This is the parent ticket to hold any tickets under this activity, including:
- Investigate the ideal browser user experience for when such a redirection takes place, to minimize user confusion.
- Build the code necessary to optimally support this experience on Tor Browser such as prioritizing .onion addresses when Alt-Svc is used.
- Correctly display the .onion Alt-Svc circuit path on the circuit display.
- Educate the user on how the redirection takes place, so that users get more familiar with the concept of onion services. We will employ appropriate “stop-and-learn” techniques to inform our users of the benefits of onion services and how they should be used.
- Continue work on our Onion-Location proposal which gives the user the option to choose whether or not onion redirect should take place.https://gitlab.torproject.org/legacy/trac/-/issues/30025Objective 2, Activity 4: Better client-side errors2020-06-16T01:02:12ZPili GuerraObjective 2, Activity 4: Better client-side errorsThis is the parent ticket to hold any tickets under this activity, including:
- Improving Tor Browser behavior when an onion site supports HTTPS but the HTTPS is not from an approved certificate.
- Fixing inconsistent messages we are sho...This is the parent ticket to hold any tickets under this activity, including:
- Improving Tor Browser behavior when an onion site supports HTTPS but the HTTPS is not from an approved certificate.
- Fixing inconsistent messages we are showing to users accessing .onion sites with self-signed certificates-
- Improving Tor Browser’s user experience and error messages when a .onion link fails.
- Providing more informative error messages back to the user to better indicate whether the issue was on the service-side, on the client-side, or on the network-side.https://gitlab.torproject.org/legacy/trac/-/issues/30029Objective 2, Activity 5: POC for Human-memorable addresses for .onion services2020-06-16T01:02:13ZPili GuerraObjective 2, Activity 5: POC for Human-memorable addresses for .onion servicesThis is the parent ticket to hold any tickets under this activity, including:
- Evaluating using HTTPS-Everywhere.
- Evaluating using HTTPS-Everywhere’s Update Channels feature to add custom onion rulesets that can be updated automatica...This is the parent ticket to hold any tickets under this activity, including:
- Evaluating using HTTPS-Everywhere.
- Evaluating using HTTPS-Everywhere’s Update Channels feature to add custom onion rulesets that can be updated automatically.
- Evaluating adding a designated file extension handler in Tor Browser to handle HTTPS-Everywhere rulesets.
- Evaluating enhancing the UI of HTTPS-Everywhere so that it educates users on how onion update channels work.https://gitlab.torproject.org/legacy/trac/-/issues/30090Make a list of potential .onion errors2020-06-16T01:10:51ZPili GuerraMake a list of potential .onion errorsLet's make a list of all potential errors that can happen when visiting .onion services to help us design the corresponding error pagesLet's make a list of all potential errors that can happen when visiting .onion services to help us design the corresponding error pagesAntonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30200Potential circuit timeout issues on onion service circuits2020-06-13T15:44:29ZGeorge KadianakisPotential circuit timeout issues on onion service circuitsThis is a master ticket to track various kinds of timeout issues we have with onion service circuits causing reachability issues.This is a master ticket to track various kinds of timeout issues we have with onion service circuits causing reachability issues.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30237Tor Browser: Improve TBB UI of hidden service client authorization2020-06-16T01:13:13ZGeorge KadianakisTor Browser: Improve TBB UI of hidden service client authorizationThis is the parent ticket for Sponsor27 Objective1 Activity1 about improving the UI of client authorization.
This used to be #14389, but it contained too many network-team-specific information so I repurposed #14389 to be about the net...This is the parent ticket for Sponsor27 Objective1 Activity1 about improving the UI of client authorization.
This used to be #14389, but it contained too many network-team-specific information so I repurposed #14389 to be about the network-team side of things, and please use this ticket for the Tor Browser side of things.
Resources about setting up client auth:
https://2019.www.torproject.org/docs/tor-onion-service.html.en#CookieAuthentication
https://lists.torproject.org/pipermail/tor-project/2019-January/002180.html
and https://github.com/torproject/tor/blob/7741b21d0e3afbfc6d60a852fce6992724c4ae71/doc/tor.1.txt#L3021
and https://github.com/torproject/tor/blob/7741b21d0e3afbfc6d60a852fce6992724c4ae71/doc/tor.1.txt#L1122Mark SmithMark Smithhttps://gitlab.torproject.org/legacy/trac/-/issues/30281Sponsor27 master ticket2020-06-13T15:40:57ZGeorge KadianakisSponsor27 master ticketThis is the master ticket for the whole Sponsor27 project.This is the master ticket for the whole Sponsor27 project.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30381Provide control port commands to ADD/REMOVE/VIEW v3 client-auth2020-06-13T15:46:25ZGeorge KadianakisProvide control port commands to ADD/REMOVE/VIEW v3 client-authWe need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382).We need control port commands so that TB can add/remove/view client auth credentials.
Furthermore, the 'add' command should be able to decrypt any existing non-decryptable descriptors in the cache (see #30382).Tor: 0.4.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/30382prop304: Implement SOCKS new HS error code2020-06-16T01:13:05ZGeorge Kadianakisprop304: Implement SOCKS new HS error codeFor TB to be able to alert the user that they need to input their client auth credentials we need an appropriate control port event.
In particular:
1) When Tor fails to decrypt the second layer of desc encryption, we issue the `CLIENT_...For TB to be able to alert the user that they need to input their client auth credentials we need an appropriate control port event.
In particular:
1) When Tor fails to decrypt the second layer of desc encryption, we issue the `CLIENT_AUTH_NEEDED <onion> <reason>` event. Tor does not go to fetch more descs from the hsdir for this onion.
2) At the same time, we store the broken descriptor into the hs cache, with a special flag that says "missing client auth" and hence `desc` is `NULL`.
3) When TB intercepts the event it presents the user with a dialogue (#30237) and adds any client auth creds with the commands from #30381.
4) As part of the #30381 commands the descriptor is decrypted.
5) TB issues another SOCKS request which uses the right descriptor and goes forward.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30454hs-v3: INTRODUCE1 trunnel code doensn't handle HS_INTRO_ACK_STATUS_CANT_RELAY2020-06-13T15:41:25ZDavid Gouletdgoulet@torproject.orghs-v3: INTRODUCE1 trunnel code doensn't handle HS_INTRO_ACK_STATUS_CANT_RELAYI'm not sure how it happens because this code got in almost at the same time but the introduction ACK status code are not synchronized with what trunnel can parse which can lead to the intro point hard asserting() if it ever tries to sen...I'm not sure how it happens because this code got in almost at the same time but the introduction ACK status code are not synchronized with what trunnel can parse which can lead to the intro point hard asserting() if it ever tries to send the status code: `HS_INTRO_ACK_STATUS_CANT_RELAY = 0x0003`.
See `cell_introduce1.trunnel`, it does not handle status code `0x0003`:
```
u16 status IN [0x0000, 0x0001, 0x0002];
```
Fortunately for us, it can NOT happen with the current code. The only call site is here:
```
/* Relay the cell to the service on its intro circuit with an INTRODUCE2
* cell which is the same exact payload. */
if (relay_send_command_from_edge(CONTROL_CELL_ID, TO_CIRCUIT(service_circ),
RELAY_COMMAND_INTRODUCE2,
(char *) request, request_len, NULL)) {
log_warn(LD_PROTOCOL, "Unable to send INTRODUCE2 cell to the service.");
/* Inform the client that we can't relay the cell. */
status = HS_INTRO_ACK_STATUS_CANT_RELAY;
goto send_ack;
}
```
... and turns out that `relay_send_command_from_edge()` can *NEVER* return anything else than 0 (we've audited all the currently supported versions, they all behave the same there).
This prevents tor from asserting in `send_introduce_ack_cell()` with:
```
/* A wrong status is a very bad code flow error as this value is controlled
* by the code in this file and not an external input. This means we use a
* code that is not known by the trunnel ABI. */
tor_assert(ret == 0);
```
There are a series of things to fix here.
1. The status code should be defined within the trunnel file and ONLY that ABI should be used. In short, `hs_intro_ack_status_t` should disappear in favor of the one that needs to be defined with trunnel. Side node, same must be done for: `hs_intro_auth_key_type_t`
2. Because clients won't be able to know what `HS_INTRO_ACK_STATUS_CANT_RELAY` is, we should remove it at once for now since it was/is never used.
3. We should add a default case to the trunnel definition so if we ever extend this later, tor will not explode or simply fail to parse the cell.
4. We should conduct an audit of the `tor_assert()` in the HS code and replace them with non fatal ones if possible.
We got very lucky here because else it would have been an easy remote relay crash so (4) is very important. One lesson is also to *NEVER* duplicate any values defined in a trunnel file. Always use the defined ABI of that trunnel spec.
End note, this was found by #15516 branch which re-used this error code and during testing, the intro point relay exploded.
All this got into 0.3.0.1-alpha.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30599Cloudflare alt-svc onions cause a different exit to be used at each request2020-06-16T01:04:17ZcypherpunksCloudflare alt-svc onions cause a different exit to be used at each requestFor some websites, such as zerobin.net which use Cloudflare's new onions, each request might cause a different exit to be used. This is bad both from a load perspective as well as a fingerprinting perspective.
Steps to reproduce: Go to ...For some websites, such as zerobin.net which use Cloudflare's new onions, each request might cause a different exit to be used. This is bad both from a load perspective as well as a fingerprinting perspective.
Steps to reproduce: Go to zerobin.net and create a new paste with "allow discussion" enabled. Post several comments and observe that the visual hash of the IP often changes with each comment. Check the circuit display to verify.https://gitlab.torproject.org/legacy/trac/-/issues/30687Implement a generic counter token bucket2020-06-13T15:44:28ZDavid Gouletdgoulet@torproject.orgImplement a generic counter token bucketWe have the `_raw_t` interface and a `_rw_t` specialized one. Many use cases only need a single counter like for instance the circuit creation DoS defense would use that. Or #15516 introduce2 rate limiting.
After a discussion with nickm...We have the `_raw_t` interface and a `_rw_t` specialized one. Many use cases only need a single counter like for instance the circuit creation DoS defense would use that. Or #15516 introduce2 rate limiting.
After a discussion with nickm, it would be wise if we can simply implement a generic counter token bucket:
```
token_bucket_ctr_t
```
... with a single bucket in it and thus could generically be used by many subsystems.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30790hs-v3: Write a proposal for an ESTABLISH_INTRO cell extension containing DoS ...2020-06-13T15:42:15ZDavid Gouletdgoulet@torproject.orghs-v3: Write a proposal for an ESTABLISH_INTRO cell extension containing DoS defense parametersThis ticket is for writing the proposal that will allow an onion service to put DoS defense parameters (at the intro point, like #15516) in the `ESTABLISH_INTRO` cell so the intro point can use those.
It is more than possible that we pr...This ticket is for writing the proposal that will allow an onion service to put DoS defense parameters (at the intro point, like #15516) in the `ESTABLISH_INTRO` cell so the intro point can use those.
It is more than possible that we probably want more than just DoS parameters in that cell.
This is related to #15516 as the parameters, initially, come from that ticket work.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30921hs-v3: Close intro circuits when cleaning up the client descriptor cache2020-06-13T15:42:45ZDavid Gouletdgoulet@torproject.orghs-v3: Close intro circuits when cleaning up the client descriptor cacheIn #28970, one of the assert indicates that we are missing the `descriptor` object when the intro point circuit opened:
```
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-f...In #28970, one of the assert indicates that we are missing the `descriptor` object when the intro point circuit opened:
```
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at ../src/or/hs_client.c:624. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_circuit_has_opened+0x2ca) [0x56345ce8027a] (on Tor 0.3.4.9 )
```
When a descriptor is removed from the client cache, the intro circuits aren't closed so there is a race where if it happens in the same main loop run that the client has an opened intro circuit for it, then it could lead to that assert.
Regardless of the cause of the assert or not, we should always close pending intro circuits when cleaning up a descriptor since once it opens, the client requires access to the descriptor object to complete the introduction (see `setup_intro_circ_auth_key()`).
Funny thought that we do that when we replace a descriptor from the client cache but not when we purge it...
This is a possible backport contender in order to avoid `BUG()` and failure of reachability client side.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30924hs-v3: Implement proposal 305 - ESTABLISH_INTRO Cell DoS Defense Extension2020-06-13T15:48:38ZDavid Gouletdgoulet@torproject.orghs-v3: Implement proposal 305 - ESTABLISH_INTRO Cell DoS Defense ExtensionTicket for implementing prop305 (see #30790).Ticket for implementing prop305 (see #30790).Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31369HSv3 descriptor support in stem [decoding]2020-06-13T10:52:54ZGeorge KadianakisHSv3 descriptor support in stem [decoding]Hello,
it would be great if stem could support v3 onion service descriptors: both to parse them and to generate them.
This would be particularly useful as part of onionbalance v3 (#26768). The old onionbalance actually generates the de...Hello,
it would be great if stem could support v3 onion service descriptors: both to parse them and to generate them.
This would be particularly useful as part of onionbalance v3 (#26768). The old onionbalance actually generates the descriptors itself in an ad-hoc way, but it would be great if we could have stem make them in the new one.
Damian asked me for an HSFETCH command that will fetch a stable v3 onion desc. I used Donncha's script from here (https://gist.github.com/DonnchaC/13b744a1e30b7d34bc26) like this:
`python tmp/hsfetch.py vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion` and that gives me the riseup onion descriptor (there is no DDG v3 onion right now).
Also, v3 descriptors are more complicated than v2 descriptors because of their double-layer encryption. You can see more info here: https://github.com/torproject/torspec/blob/master/rend-spec-v3.txt#L1046
https://github.com/torproject/tor/blob/0acfd7dcee2a4473eba05a53d6df2d6d4fe2050b/src/feature/hs/hs_descriptor.c#L2639
Damian, let me know how that looks like to you and how we can help. We plan to start working on Onionbalance v3 at mid-to-late August, but if this is something we can have at a reasonaable timeframe we can potentially delay the descriptor parts of it for some time until stem support exists.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31371hs: Add DoS defense counter to DoS heartbeat message2020-06-13T15:44:09ZDavid Gouletdgoulet@torproject.orghs: Add DoS defense counter to DoS heartbeat messageNow that #15516 is merged, we'll soon enable those defenses and it would be nice to have the counter of how many introduction were rejected due to DoS defenses.Now that #15516 is merged, we'll soon enable those defenses and it would be nice to have the counter of how many introduction were rejected due to DoS defenses.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31375hs: Crash in token_bucket_ctr_refill() of the INTRO2 DoS defense2020-06-13T15:44:12ZDavid Gouletdgoulet@torproject.orghs: Crash in token_bucket_ctr_refill() of the INTRO2 DoS defenseRan my relay for some minutes with master (merged #15516) and the HS DoS defenses enabled. Relay died with this:
```
Tor 0.4.2.0-alpha-dev (git-0acfd7dcee2a4473) died: Caught signal 8
/home/tor/git/tor/src/app/tor(+0x20d359)[0x5594030b1...Ran my relay for some minutes with master (merged #15516) and the HS DoS defenses enabled. Relay died with this:
```
Tor 0.4.2.0-alpha-dev (git-0acfd7dcee2a4473) died: Caught signal 8
/home/tor/git/tor/src/app/tor(+0x20d359)[0x5594030b1359]
/home/tor/git/tor/src/app/tor(token_bucket_ctr_refill+0x3b)[0x55940304c33b]
/home/tor/git/tor/src/app/tor(token_bucket_ctr_refill+0x3b)[0x55940304c33b]
/home/tor/git/tor/src/app/tor(hs_dos_can_send_intro2+0x45)[0x559402fb6ba5]
/home/tor/git/tor/src/app/tor(rend_mid_introduce_legacy+0x136)[0x559402ff7096]
/home/tor/git/tor/src/app/tor(hs_intro_received_introduce1+0x2ce)[0x5594030457ee]
/home/tor/git/tor/src/app/tor(rend_process_relay_cell+0x1bf)[0x559402ff643f]
/home/tor/git/tor/src/app/tor(+0xb9105)[0x559402f5d105]
/home/tor/git/tor/src/app/tor(+0xb9b60)[0x559402f5db60]
/home/tor/git/tor/src/app/tor(circuit_receive_relay_cell+0x490)[0x559402f5f590]
/home/tor/git/tor/src/app/tor(command_process_cell+0x3f8)[0x559402f40ed8]
/home/tor/git/tor/src/app/tor(channel_tls_handle_cell+0x39b)[0x559402f2078b]
/home/tor/git/tor/src/app/tor(+0xa5a9c)[0x559402f49a9c]
/home/tor/git/tor/src/app/tor(connection_handle_read+0xa0d)[0x559402f0dd0d]
/home/tor/git/tor/src/app/tor(+0x6ef1e)[0x559402f12f1e]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x1e8f8)[0x7f15b29208f8]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x53f)[0x7f15b292133f]
/home/tor/git/tor/src/app/tor(do_main_loop+0xd9)[0x559402f14209]
/home/tor/git/tor/src/app/tor(tor_run_main+0x128d)[0x559402f01d9d]
/home/tor/git/tor/src/app/tor(tor_main+0x3a)[0x559402eff1da]
/home/tor/git/tor/src/app/tor(main+0x19)[0x559402efed69]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f15b1bbbb97]
```Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31492Update hsv3 spec for unreachable/failed single onion retries using 3 hops2020-06-13T15:44:30ZteorUpdate hsv3 spec for unreachable/failed single onion retries using 3 hopsThis ticket is the spec part of #23818, #23507, and #23588.This ticket is the spec part of #23818, #23507, and #23588.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31541hs-v3: Client can re-pick bad intro points2020-06-13T15:44:44ZDavid Gouletdgoulet@torproject.orghs-v3: Client can re-pick bad intro pointsOk this one took me a while to figure out!
This is sorta related to #25882 as it is a bug that makes the client retry constantly the same intro point even though it was flagged as having an error.
Problem lies in `client_get_random_int...Ok this one took me a while to figure out!
This is sorta related to #25882 as it is a bug that makes the client retry constantly the same intro point even though it was flagged as having an error.
Problem lies in `client_get_random_intro()` which randomly selects an intro point from the descriptor. Sparing the detail, this is where it goes wrong:
```
ip = smartlist_get(usable_ips, idx);
smartlist_del(usable_ips, idx);
```
... and then we use `ip` to check if usable and if yes, we connect to it.
~~We can't `del()` the value from the list until we are done with the `ip` object. The `smartlist_get()` returns a pointer to location *in the list* so if we change the list order right after acquiring the reference, we are accessing bad things, possibly junk.~~
~~So basically, junk can be used, the wrong IP can be used even though it would not pass the `intro_point_is_usable()` if it was correct pointer.~~
I was able to find this using a pathological case where the HS pins its intro point to 3 specific nodes. So, even upon a restart or desc rotation, the same IPs are re-used but with different auth key.
If a client had already connected to that service and thus had those IPs in its failure cache, it will fail to eternity to connect to the service because it basically never realize it needs to refetch a new descriptor.
Even though there is a catch all with `hs_client_any_intro_points_usable()` before extending to an intro point, the problem lies with the above which can make the code NEVER pick a certain intro point so the catch all always validate to true since there is one intro point in the list that was never tried.
This is very bad for reachability, network load, but also simple "code safety". I strongly recommend backport to our maintained version >= 032.
Fortunately for us, the fix is trivial, we should only `del()` when done with the IP object.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31545CID 1452819: nul-terminated string handling, possibly spurious2020-06-13T15:44:46ZteorCID 1452819: nul-terminated string handling, possibly spuriousBug introduced by #21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
...Bug introduced by #21003, copying sponsors and tags.
```
/src/feature/nodelist/describe.c: 77 in format_node_description()
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
76 if (has_addr) {
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "tor_addr_to_str", which expects a null-terminated string.
77 tor_addr_to_str(cp, addr, TOR_ADDR_BUF_LEN, 1);
78 }
79
80 return buf;
81 }
82
/src/feature/nodelist/describe.c: 70 in format_node_description()
64 cp += 4;
65 }
66 if (addr32h) {
67 struct in_addr in;
68 in.s_addr = htonl(addr32h);
69 tor_inet_ntoa(&in, cp, INET_NTOA_BUF_LEN);
CID 1452819: (STRING_NULL)
Passing unterminated string "cp" to "strlen", which expects a null-terminated string.
70 cp += strlen(cp);
71 }
72 if (addr32h && has_addr) {
73 memcpy(cp, " and ", 5);
74 cp += 5;
75 }
```
I think the best fix for this issue is using strncpy() rather than memcpy().Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31548hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro po...2020-06-13T15:46:40ZDavid Gouletdgoulet@torproject.orghs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro pointsDuring my testing of #30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_intro_points...During my testing of #30200, I ended up with service descriptor with 4 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3 (default).
Further investigation confirmed this by adding a log in the `decode_intro_points()` function which showed me 4 intro points.
I haven't found out why but one feature of HS is that we launch `HiddenServiceNumIntroductionPoints` + 2 intro circuits in parallel and the first one to finish are picked.
It appears that more than the defined value can finish at the same time and will be picked.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31561hs-v3: Service can keep unused intro points in its list2020-06-13T15:44:53ZDavid Gouletdgoulet@torproject.orghs-v3: Service can keep unused intro points in its listTor always selects an extra number of intro points in addition to the configured `HiddenServiceNumIntroductionPoints`.
It launches all of them and the first `NumIntro...` to finish are used (considering #31548 is resolved).
Once the ci...Tor always selects an extra number of intro points in addition to the configured `HiddenServiceNumIntroductionPoints`.
It launches all of them and the first `NumIntro...` to finish are used (considering #31548 is resolved).
Once the circuit of the remaining intro opens, we notice that we have too many and then re-purpose the extra ones.
However, I've noticed that sometimes establishing an intro circuit timeouts during build, basically expiring due to our CBT policy. In that case, the circuit is simply close but the intro point remains in the service descriptor list.
This is bad because of #31548, this means an intro point can end up in the descriptor even though the service never established any circuits to it...
We simply need to callback into the HS subsystem when we are expiring an HS circuit so appropriate actions can be taken such as in this case, removing the IP from the list.Tor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31652hs-v3: Service circuit retry limit should not close a valid circuit2020-06-13T15:45:19ZDavid Gouletdgoulet@torproject.orghs-v3: Service circuit retry limit should not close a valid circuitContext: Lets say a service has 3 intro circuits opened and stable.
Now, imagine one circuit collapses, like for instance the intro point restarted "tor" after an update. Our code is designed to retry 3 times that is once every second a...Context: Lets say a service has 3 intro circuits opened and stable.
Now, imagine one circuit collapses, like for instance the intro point restarted "tor" after an update. Our code is designed to retry 3 times that is once every second and then give up on the intro point.
What it looks like:
Every second, `run_build_circuit_event()` is run and launches intro circuit(s) if we are missing any. For each IP, it will increment the `circuit_retries` counter but does not actually look at it to decide to launch or not.
Before that event, also every 1 second, `cleanup_intro_points()` checks that every intro point has not expired, fell off the consensus or that `circuit_retries` is greater than (>) `MAX_INTRO_POINT_CIRCUIT_RETRIES = 3`.
Putting this together, imagine now that the first 3 attempts failed for whatever reasons and then we launch a 4th one because `circuit_retries = 3`, it does pass validation of `> MAX_INTRO_POINT_CIRCUIT_RETRIES` so then a circuit is launched and that very one succeeds.
Because `circuit_retries` is now 4 then the next second, `cleanup_intro_points()` removes the IP and closes the valid open established circuit...
I've observed the above a surprising amount of time because booting a tor relay takes some seconds mostly due to the diff-cache parsing.
In a nutshell, we should NOT launch a circuit if we reached the max retries for an intro point. This back and forth of opening a circuit and then deciding that we went over the limit makes no sense in the first place.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31682CID 1453653: Integer handling (NEGATIVE_RETURNS) in build_establish_intro_dos...2020-06-13T15:46:35ZteorCID 1453653: Integer handling (NEGATIVE_RETURNS) in build_establish_intro_dos_extension()trn_cell_extension_dos_encoded_len() returns ssize_t, but trn_cell_extension_field_setlen_field() takes size_t.
This looks like a bug on #30924, copying sponsor fields across.
```
/src/feature/hs/hs_cell.c: 532 in build_establish_intro_...trn_cell_extension_dos_encoded_len() returns ssize_t, but trn_cell_extension_field_setlen_field() takes size_t.
This looks like a bug on #30924, copying sponsor fields across.
```
/src/feature/hs/hs_cell.c: 532 in build_establish_intro_dos_extension()
528 /* Set the field with the encoded DoS extension. */
529 dos_ext_encoded_len = trn_cell_extension_dos_encoded_len(dos_ext);
530 /* Set length field and the field array size length. */
531 trn_cell_extension_field_set_field_len(field, dos_ext_encoded_len);
CID 1453653: Integer handling issues (NEGATIVE_RETURNS)
"dos_ext_encoded_len" is passed to a parameter that cannot be negative.
532 trn_cell_extension_field_setlen_field(field, dos_ext_encoded_len);
533 /* Encode the DoS extension into the cell extension field. */
534 field_array = trn_cell_extension_field_getarray_field(field);
```Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31958connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)-...2020-06-13T15:46:20ZDavid Gouletdgoulet@torproject.orgconnection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failedHmm, I just noticed this on one of my test relay:
```
Sep 14 17:35:18.196 [warn] tor_bug_occurred_(): Bug: src/feature/dircommon/directory.c:229: connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NU...Hmm, I just noticed this on one of my test relay:
```
Sep 14 17:35:18.196 [warn] tor_bug_occurred_(): Bug: src/feature/dircommon/directory.c:229: connection_dir_is_anonymous: Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: Tor 0.4.2.0-alpha-dev (git-796a9b37ea346f41): Non-fatal assertion !(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL) failed in connection_dir_is_anonymous at src/feature/dircommon/directory.c:229. Stack trace: (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(log_backtrace_impl+0x46) [0x56174b20aae6] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_bug_occurred_+0x16c) [0x56174b205d9c] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_dir_is_anonymous+0x131) [0x56174b0ef421] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(directory_handle_command+0x1ef) [0x56174b19755f] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_dir_process_inbuf+0x95) [0x56174b0efb85] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(connection_handle_read+0xa0d) [0x56174b064bfd] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(+0x6fe0e) [0x56174b069e0e] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x1e8f8) [0x7f65e17278f8] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x53f) [0x7f65e172833f] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(do_main_loop+0xd9) [0x56174b06b0f9] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_run_main+0x128d) [0x56174b058c8d] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(tor_main+0x3a) [0x56174b0560ca] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(main+0x19) [0x56174b055c59] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65e09c2b97] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
Sep 14 17:35:18.257 [warn] Bug: /root/git/tor/src/app/tor(_start+0x2a) [0x56174b055caa] (on Tor 0.4.2.0-alpha-dev 796a9b37ea346f41)
```
This is recent code that reject HSDir single hop connections (#24964). Offending piece of code is:
```
/* Get the previous channel to learn if it is a client or relay link. */
if (BUG(CONST_TO_OR_CIRCUIT(circ)->p_chan == NULL)) {
log_info(LD_DIR, "Rejected HSDir request: no p_chan");
return false;
}
```
Not sure why this can BUG()...Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32016spec: ClientAuth option of ADD_ONION is only v22020-06-13T15:46:25ZDavid Gouletdgoulet@torproject.orgspec: ClientAuth option of ADD_ONION is only v2It should be specified in control-spec.txt. #30381 is the answer for client authorization v3 side.It should be specified in control-spec.txt. #30381 is the answer for client authorization v3 side.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32020hsv3: Client do not report failing circuit back into HS subsystem2020-06-13T15:47:43ZDavid Gouletdgoulet@torproject.orghsv3: Client do not report failing circuit back into HS subsystemThis is a subtask of the bigger larger problem in #25882.
A v2 client does report intro point failures within `circuit_about_to_free()` but not v3.
Actually, any HS circuit client side is not looked at. The `hs_circ_cleanup()` was inte...This is a subtask of the bigger larger problem in #25882.
A v2 client does report intro point failures within `circuit_about_to_free()` but not v3.
Actually, any HS circuit client side is not looked at. The `hs_circ_cleanup()` was intended for this as the entry point in the HS subsystem but only the service uses it.
Intro circuit failure needs to be noted in the failure cache (`hs_cache_client_intro_state_note()`).
Rendezvous circuit need to be also somehow handled. If the RP circuit keeps closing on us, we might want to stop trying maybe?
Same goes for HSDir circuit, if they close, client needs to be notified and launch a refetch.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32021hs-v3: Handle rendezvous client circuit build expire properly2020-06-13T15:46:26ZDavid Gouletdgoulet@torproject.orghs-v3: Handle rendezvous client circuit build expire properlyThis is a subtask of the bigger larger problem in #25882.
In `circuit_expire_building()`, we have this code path:
```
if (!(TO_ORIGIN_CIRCUIT(victim)->hs_circ_has_timed_out)) {
switch (victim->purpose) {
case CIRCUIT_PU...This is a subtask of the bigger larger problem in #25882.
In `circuit_expire_building()`, we have this code path:
```
if (!(TO_ORIGIN_CIRCUIT(victim)->hs_circ_has_timed_out)) {
switch (victim->purpose) {
case CIRCUIT_PURPOSE_C_REND_READY:
/* We only want to spare a rend circ if it has been specified in
* an INTRODUCE1 cell sent to a hidden service. A circ's
* pending_final_cpath field is non-NULL iff it is a rend circ
* and we have tried to send an INTRODUCE1 cell specifying it.
* Thus, if the pending_final_cpath field *is* NULL, then we
* want to not spare it. */
if (TO_ORIGIN_CIRCUIT(victim)->build_state &&
TO_ORIGIN_CIRCUIT(victim)->build_state->pending_final_cpath ==
NULL)
break;
```
Basically, this `pending_final_cpath` is only used by v2 which means v3 is not handle in that case.
And that case is: if we want to expire a rendezvous client circuit that is ready but has been waiting for a while on the introduction circuit as in its cookie has been sent in the `INTRODUCE1`, we want to spare it until the intro point client circuit collapses.
Because v3 is not handled in the above, rendezvous circuit will be tagged as timed out with the general cutoff instead of being kept until the intro circuit is ready or times out. And we time out intro circuit being established much later than an established rendezvous circuit for which the `general_cutoff` will be applied on.
Bottom line is that we need a flag within the rendezvous client circuit (probably hs_ident_t?) that its cookie was put in the INTRO1 cell and that we are waiting on the intro side signalling the `circuit_expire_building()` that it should wait more on that circuit.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32063CID 1454769: Resource leaks in build_establish_intro_dos_extension()2020-06-13T15:46:35ZteorCID 1454769: Resource leaks in build_establish_intro_dos_extension()Caused by #31682, which was a fix to another coverity issue.
```
CID 1454769: Resource leaks (RESOURCE_LEAK)
/src/feature/hs/hs_cell.c: 533 in build_establish_intro_dos_extension()
527 TRUNNEL_DOS...Caused by #31682, which was a fix to another coverity issue.
```
CID 1454769: Resource leaks (RESOURCE_LEAK)
/src/feature/hs/hs_cell.c: 533 in build_establish_intro_dos_extension()
527 TRUNNEL_DOS_PARAM_TYPE_INTRO2_BURST_PER_SEC,
528 service_config->intro_dos_burst_per_sec);
529
530 /* Set the field with the encoded DoS extension. */
531 ret = trn_cell_extension_dos_encoded_len(dos_ext);
532 if (BUG(ret <= 0)) {
CID 1454769: Resource leaks (RESOURCE_LEAK)
Variable "field" going out of scope leaks the storage it points to.
533 return -1;
534 })
```Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32094hs-v3: Stop using ip->circuit_established flag2020-06-13T15:46:39ZDavid Gouletdgoulet@torproject.orghs-v3: Stop using ip->circuit_established flagSince #31548, where we forgot to look if the service intro circuit was established, we rely on `ip->circuit_established` flag to know if we can use the IP (and in many other places as well).
However, this is a bit of a "duplication" of ...Since #31548, where we forgot to look if the service intro circuit was established, we rely on `ip->circuit_established` flag to know if we can use the IP (and in many other places as well).
However, this is a bit of a "duplication" of effort because we have the HS circuitmap that keeps all the intro circuits conveniently indexed by IP auth key.
When a circuit closes or is repurposed, that HS map is cleaned up with `hs_circ_cleanup()` so regardless what caused the circuit to disappear, our map will always be updated properly.
I believe we should stop relying on the `ip->circuit_established` flag so in the future we don't get out of sync with the map by mistake or assume state based solely on this flag. The HS map is the only real valid state we should be looking at for HS circuit state.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32141single onion v3 IPv6 intro circuit BUG() warnings2020-06-13T15:46:54Zteorsingle onion v3 IPv6 intro circuit BUG() warningsLooks like some of our assertions are wrong in single onion IPv6 mode, but chutney still succeeds:
```
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) fail...Looks like some of our assertions are wrong in single onion IPv6 mode, but chutney still succeeds:
```
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at src/feature/hs/hs_client.c:491. Stack trace: (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at src/feature/hs/hs_client.c:685. Stack trace: (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:491: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:685: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
```
https://travis-ci.org/torproject/tor/jobs/599435523#L3431Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32356hs-v3: Memory leak in rend_client_get_random_intro_impl()2020-06-13T15:47:44ZDavid Gouletdgoulet@torproject.orghs-v3: Memory leak in rend_client_get_random_intro_impl()From coverity report:
```
** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
___________________________________________________________________________________...From coverity report:
```
** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
________________________________________________________________________________________________________
*** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
1055 usable_nodes = smartlist_new();
1056 smartlist_add_all(usable_nodes, entry->parsed->intro_nodes);
1057
1058 /* Get service ID so we can use it to query the failure cache. If we fail to
1059 * parse it, this cache entry is no good. */
1060 if (BUG(rend_get_service_id(entry->parsed->pk, service_id) < 0)) {
>>> CID 1455168: Resource leaks (RESOURCE_LEAK)
>>> Variable "usable_nodes" going out of scope leaks the storage it points to.
1061 return NULL;
1062 }
```
Was just introduced couple days ago.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32542hs-v3: Add the 2 missing SOCKS extended errors from prop3042020-06-16T01:10:52ZDavid Gouletdgoulet@torproject.orghs-v3: Add the 2 missing SOCKS extended errors from prop304The two missing codes are the intro failure and RP failure.
```
* X'F2' Onion Service Introduction Failed
Client failed to introduce to the service meaning the descriptor was
found but the service is not anymore at the ...The two missing codes are the intro failure and RP failure.
```
* X'F2' Onion Service Introduction Failed
Client failed to introduce to the service meaning the descriptor was
found but the service is not anymore at the introduction points. The
service has likely changed its descriptor or is not running.
* X'F3' Onion Service Rendezvous Failed
Client failed to rendezvous with the service which means that the client
is unable to finalize the connection.
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32543spec: Merge prop304 into torspec.git in socks-extensions.txt2020-06-13T15:48:21ZDavid Gouletdgoulet@torproject.orgspec: Merge prop304 into torspec.git in socks-extensions.txt#30382 has been merged upstream, prop304 needs to be put in socks-extensions.txt and then `Closed`.#30382 has been merged upstream, prop304 needs to be put in socks-extensions.txt and then `Closed`.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32546hs-v3: Report invalid onion address SOCKS5 extended error code2020-06-16T01:10:52ZDavid Gouletdgoulet@torproject.orghs-v3: Report invalid onion address SOCKS5 extended error codeFrom prop304, continuing on after #30382, add a new error code to indicate invalid address.
This is the little-t tor side of #30022.From prop304, continuing on after #30382, add a new error code to indicate invalid address.
This is the little-t tor side of #30022.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32562Allow ONION_CLIENT_AUTH_ADD credentials to be made permanent2020-06-13T15:48:25ZGeorge KadianakisAllow ONION_CLIENT_AUTH_ADD credentials to be made permanentThe Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.The Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32563Merge HSv3 spec fixes we found during onionbalance creation2020-06-13T15:48:25ZGeorge KadianakisMerge HSv3 spec fixes we found during onionbalance creationThere are a few issues with the v3 spec that we found out as we were implementing onionbalance. We should merge them.
Examples:
- https://github.com/asn-d6/stem/pull/2#discussion_r348847261
- The MAC description in the descriptor encryp...There are a few issues with the v3 spec that we found out as we were implementing onionbalance. We should merge them.
Examples:
- https://github.com/asn-d6/stem/pull/2#discussion_r348847261
- The MAC description in the descriptor encryption is wrong.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32617spec: Merge prop305 into rend-spec-v3.txt2020-06-13T15:48:38ZDavid Gouletdgoulet@torproject.orgspec: Merge prop305 into rend-spec-v3.txtNow that #30924 was merged, we need to close prop305 and merge it in `rend-spec-v3.txt.Now that #30924 was merged, we need to close prop305 and merge it in `rend-spec-v3.txt.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32645Update URL bar onion indicators2020-12-11T13:05:04ZAntonelaantonela@torproject.orgUpdate URL bar onion indicatorsSince FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].
As part of S27, I'm working on unifying (and simplifying) t...Since FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].
As part of S27, I'm working on unifying (and simplifying) the brand presence of onions in Tor Browser, either for referring to the network or to the onion services.
I'm opening this ticket to discuss the following:
- are we ok following the Firefox approach and removing green icons from the URL bar?
- are we ok unifying the visual anchor for onions and onion routing at the URL bar and also at the circuit display?
- are we ok removing EV label from the URL bar and leave it at the identity doorhanger?
[1]FF70 https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/
[2]CH69 https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html
[*]TB8 https://trac.torproject.org/projects/tor/wiki/org/teams/UxTeam/Misc/OnionSecurityIndicatorrichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/32664hs-v3: Segfault in hs_circ_service_get_established_intro_circ()2020-06-13T15:48:48ZDavid Gouletdgoulet@torproject.orghs-v3: Segfault in hs_circ_service_get_established_intro_circ()Reported by atagar on IRC:
```
<+atagar> Looks like stem's jenkins runs are presently failing due to tor segfaults: https://paste.debian.net/plain/1119133
```
The report:
```
...
Dec 02 17:03:09.077 [notice] Configured to measure dire...Reported by atagar on IRC:
```
<+atagar> Looks like stem's jenkins runs are presently failing due to tor segfaults: https://paste.debian.net/plain/1119133
```
The report:
```
...
Dec 02 17:03:09.077 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
Dec 02 17:03:09.085 [warn] Controller gave us config lines that didn't validate: Unknown option 'bombay'. Failing.
Dec 02 17:03:09.085 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742
Dec 02 17:03:09.088 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
Dec 02 17:03:09.225 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
============================================================ T= 1575306189
Tor 0.4.3.0-alpha-dev died: Caught signal 11
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x21ceb5)[0x56360d945eb5]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_circ_service_get_established_intro_circ+0x27)[0x56360d8327e7]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_circ_service_get_established_intro_circ+0x27)[0x56360d8327e7]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_service_run_scheduled_events+0x14ff)[0x56360d849ccf]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x72961)[0x56360d79b961]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x762f3)[0x56360d79f2f3]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f6688b925a0]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(do_main_loop+0xe5)[0x56360d79e565]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(tor_run_main+0x122d)[0x56360d78ba2d]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(tor_main+0x3a)[0x56360d7891da]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(main+0x19)[0x56360d788d59]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f66873e72e1]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(_start+0x2a)[0x56360d788daa]
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32667CID 1456199: Resource leak in test_hs_control_store_permanent_creds()2020-06-13T15:48:49ZGeorge KadianakisCID 1456199: Resource leak in test_hs_control_store_permanent_creds()```
** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
________________________________________________________________________________________________________
**...```
** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
________________________________________________________________________________________________________
*** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
528
529 #ifdef _WIN32
530 ret = mkdir(perm_creds_dir);
531 #else
532 ret = mkdir(perm_creds_dir, 0700);
533 #endif
>>> CID 1456199: Resource leaks (RESOURCE_LEAK)
>>> Variable "perm_creds_dir" going out of scope leaks the storage it points to.
534 tt_int_op(ret, OP_EQ, 0);
535
536 get_options_mutable()->ClientOnionAuthDir = perm_creds_dir;
537 }
538
539 tor_free(args);
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32709hsv3: Support onionbalance keys when handling INTRO2 cells2020-06-13T15:49:02ZGeorge Kadianakishsv3: Support onionbalance keys when handling INTRO2 cellsWe have encountered a small issue with onionbalance viability for v3s.
While the descriptor cross-certificates are no longer an issue (#29583), there is an issue with the ntor handshake during the INTRODUCE1/INTRODUCE2 handshake between...We have encountered a small issue with onionbalance viability for v3s.
While the descriptor cross-certificates are no longer an issue (#29583), there is an issue with the ntor handshake during the INTRODUCE1/INTRODUCE2 handshake between the client and service.
In particular, as specified in rend-spec-v3.txt [NTOR-WITH-EXTRA-DATA] the subcredential (which includes the onion address) is used as part of the ntor key material to generate end-to-end encryption keys and MAC keys so that the service can communicate with the client:
```
To make an INTRODUCE1 cell, the client must know a public encryption
key B for the hidden service on this introduction circuit. The client
generates a single-use keypair:
x,X = KEYGEN()
and computes:
intro_secret_hs_input = EXP(B,x) | AUTH_KEY | X | B | PROTOID
info = m_hsexpand | subcredential
hs_keys = KDF(intro_secret_hs_input | t_hsenc | info, S_KEY_LEN+MAC_LEN)
ENC_KEY = hs_keys[0:S_KEY_LEN]
MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN]
```
The issue here is that when the client prepares the INTRO1 cell, it uses the subcredential of the frontend OBv3 service, but the INTRO2 cell actually goes to a backend OBv3 instance which has a different subcredential. This causes the backend instance to not be able to verify the MAC of the cell, and generally finish the ntor handshake....Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/33035create strings for onion service error pages2020-06-16T01:10:51ZKathleen Bradecreate strings for onion service error pagesFor sponsor 27 O2A4 (Better client-side errors), we need strings that can be localized for each onion service error. There are 7 errors listed in ticket:30090#comment:9.
We are implementing error pages that look like Antonela's desig...For sponsor 27 O2A4 (Better client-side errors), we need strings that can be localized for each onion service error. There are 7 errors listed in ticket:30090#comment:9.
We are implementing error pages that look like Antonela's design at: https://onion-error.glitch.me/
For each of the above errors (XF0-XF6) we need the following strings:
* **Page/tab title** ("Problem loading page" in above design; you can see this when you hover over the tab).
* **Header** (a title; "404 - Onion Not Found" in above design)
* **Short description** (about one line)
* **Long description** (optional; Firefox uses simple HTML for some long descriptions but this may make localization difficult).
* **Learn more URL** (optional)
Note: for XF4 and XF5, users will only see an error page with the above strings if they dismiss the prompt without providing client authorization (see #30237).
Tor specs (includes a description of each error):
* ExtendedErrors: https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1823
* PROP304: https://gitweb.torproject.org/torspec.git/tree/proposals/304-socks5-extending-hs-error-codes.txt
Related browser and UX tickets:
#19251 #30090 #23545
Related tor tickets:
#30382 #32542 #32546
Pili and Antonela -- can you coordinate with the right people to produce the English strings so we can begin the localization process soon?https://gitlab.torproject.org/legacy/trac/-/issues/33139New Identity should remove v3 client auth ephemeral keys2020-06-13T15:50:39ZMark SmithNew Identity should remove v3 client auth ephemeral keysAs discussed in ticket:19757#comment:31 through comment 34, tor should remove all of the ephemeral v3 client authorization keys when a NEWNYM signal is received (new identity).As discussed in ticket:19757#comment:31 through comment 34, tor should remove all of the ephemeral v3 client authorization keys when a NEWNYM signal is received (new identity).Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33148hs-v3: Clean cached descriptor(s) on ONION_CLIENT_AUTH_REMOVE2020-06-13T15:50:40ZDavid Gouletdgoulet@torproject.orghs-v3: Clean cached descriptor(s) on ONION_CLIENT_AUTH_REMOVEWhen a client authorization is removed with the control command `ONION_CLIENT_AUTH_REMOVE`, we should also remove the associated descriptor from the cache else the .onion is still accessible even though the credentials have been removed....When a client authorization is removed with the control command `ONION_CLIENT_AUTH_REMOVE`, we should also remove the associated descriptor from the cache else the .onion is still accessible even though the credentials have been removed.
Found by mcs/brade/acat during testing: https://trac.torproject.org/projects/tor/ticket/19757#comment:31Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33707Swap out onion icon in circuit display with new one2020-06-16T01:12:02ZrichardSwap out onion icon in circuit display with new onerichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/33873client: Send back SOCKS extended error F6 in case of bad hostname2020-06-13T15:53:01ZDavid Gouletdgoulet@torproject.orgclient: Send back SOCKS extended error F6 in case of bad hostnameWith the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoie...With the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoieqw.onion`.
Problem is that we only send back the `F6` code if the address was identified, by length, as a v3. We should handle the `BAD_HOSTNAME` error code from `parse_extended_hostname()` and thus send back that extended error.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org