Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-03-22T16:56:26Zhttps://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/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/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/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/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/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: unspecified