Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:40:51Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1949set up a hidden service without using a filesystem directory?2020-06-13T14:40:51ZRoger Dingledineset up a hidden service without using a filesystem directory?In the original hidden services model, the expert user would set up a directory on the disk somewhere, edit her torrc to configure a hidden service to write its hostname and key in that directory, start tor, and go look in that directory...In the original hidden services model, the expert user would set up a directory on the disk somewhere, edit her torrc to configure a hidden service to write its hostname and key in that directory, start tor, and go look in that directory to find out the new name for the hidden service.
That model sucks if we want hidden services to be easy and safe for ordinary users.
In particular, there are two reasons why it's bad. First, the Tor client runs as whatever user it runs as, and the user needs to pick a directory that Tor can write to and read from. Where that might be probably varies from Linux distro to distro. Second, the private key of the service gets written unencrypted to disk. We could imagine expert users who know how to handle that, but we can also imagine that most users won't.
So it would be good to make an easier way to do it. One way would be to allow controllers to set up hidden services. The controller could even remember the key (and store it in a safe way), and import it to Tor when it connects to the control port. (We don't want controllers generating hidden service keys though -- that's Tor's job.)
I could imagine an API in the control protocol that allows this -- with operations like "make me a new hidden service and tell me the key" or "here's the key, please set up a hidden service". I wonder if there's a more general way to extend the controller protocol though?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2555Finish 'encrypted services' proposal2020-06-13T14:48:52ZRoger DingledineFinish 'encrypted services' proposalMany hidden services use the hidden service design for its incidental properties, such as end-to-end encryption, self-authenticating names, and usability properties of knowing you're going through Tor. They suffer from the performance an...Many hidden services use the hidden service design for its incidental properties, such as end-to-end encryption, self-authenticating names, and usability properties of knowing you're going through Tor. They suffer from the performance and robustness issues of hidden services when (maybe) they don't need to.
We should offer a way to run a Tor hidden service where the server-side rendezvous circuits are just one hop.
Step one is to finish the proposal.Tor: 0.2.8.x-finalJohn BrooksJohn Brookshttps://gitlab.torproject.org/legacy/trac/-/issues/3521Allow controllers to retrieve HS descriptors from Tor2020-06-15T23:15:49ZRobert RansomAllow controllers to retrieve HS descriptors from TorTor: 0.2.8.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/3523Allow controllers to post HS descriptors to the HSDir system2020-06-13T18:28:21ZRobert RansomAllow controllers to post HS descriptors to the HSDir systemTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4862Consider disabling dynamic intro point formula (numerology)2020-06-13T14:16:41ZArturo FilastòConsider disabling dynamic intro point formula (numerology)This ticket was repurposed and it's now about discussing the dynamic formula for determining the number of introduction points of a hidden service.
The formula leaks the popularity of the hidden service on an hourly basis. Furthermore, ...This ticket was repurposed and it's now about discussing the dynamic formula for determining the number of introduction points of a hidden service.
The formula leaks the popularity of the hidden service on an hourly basis. Furthermore, it's memoryless which causes the hidden service to use a much bigger number of introduction points than normal (comment:15:ticket:15513).
----
In #3825 rransom proposed to tune the number of IP to rebuilt once one expires based on the history of the Tor HS usage. I believe these numbers are not optimal and there should be a better way to do this.
These are the first numbers that I will try to estimate:
I = number of intro points
C = Connections made to an IP in it's lifetime
T = Total number of connections made to the HS in 24 hours
What we are interested in estimating is the value of NUM_INTRO_POINTS_MAX and this is based on the estimation of C. To determine this we will consider this equation:
`I = T/C`
I believe it is reasonable to suppose that a very busy HS will at most have 1M connections in 24 hours. This means that:
`I = 1'000'000/C`
Currently C is set to 16384. I am not sure why this number was chosen, but if this number is good we would need to set the value of I to 61.
Lets take for granted that 61 is a good value for NUM_INTRO_POINTS_MAX, this means that the number of active IP at a given time should be in the range of 3-61.
For this reason I believe it would be good to have the number of IP to recreate to be in the range of 1-20 dependent on the history of a Tor HS.
The basic thing we can do is use a linear function to determine this number x. We want a linear function that has these properties:
`f(0) = 1``f(4/3) = NUM_INTRO_POINTS_MAX ``(supposing that for lifetime of IP tends to end the fraction (time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT) -> 4/3)`
This leads us to this:
`x = (1 - NUM_INTRO_POINTS_MAX)*((time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT)) + 1`
in the case of NUM_INTRO_POINTS_MAX = 20 this means:
`x = 25.3333333 * (time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT) + 1`
A better way to do this is have an exponential function that converges asymptotically to 20.
Does this seem sane?Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7803Clients shouldn't send timestamps in INTRODUCE1 cells2020-06-13T14:26:03ZRobert RansomClients shouldn't send timestamps in INTRODUCE1 cells0.2.3.x (and later) stable releases don't look at the timestamp field. As soon as 0.2.2.x is EOLed, clients should stop sending timestamps (send `(time_t)0` instead).0.2.3.x (and later) stable releases don't look at the timestamp field. As soon as 0.2.2.x is EOLed, clients should stop sending timestamps (send `(time_t)0` instead).Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8106Make .onion addresses harder to harvest by directory servers2020-06-13T14:38:09ZGeorge KadianakisMake .onion addresses harder to harvest by directory serversCurrently, an `HSDir` can relax on the hash ring, receive descriptor lookups and harvest .onions for days. Furthermore, it doesn't even have to change identity keys, since its position on the hash ring changes every day (because of the t...Currently, an `HSDir` can relax on the hash ring, receive descriptor lookups and harvest .onions for days. Furthermore, it doesn't even have to change identity keys, since its position on the hash ring changes every day (because of the timestamp), so it gets new .onions all the time.
This ticket is for research on how we can make .onion addresses harder to harvest.
Proposal 143 has some ideas that will reduce the exposure of .onions, but it doesn't solve the problem itself.
On actual solutions, Robert posted:
https://lists.torproject.org/pipermail/tor-dev/2012-September/004026.html
some months ago. I don't have the cryptographic skills to robustly analyze his idea, but if this is the only thing we have, we should point some cryptographers at it so that it gets some comments.
I also seem to recall that there was a paper suggesting hidden services to create ephemeral .onion addresses or something, but after asking Karsten and crawling anonbib I'm not sure that such a paper exists.
Are there any other proposed solutions out there? If not, this might be a fun research problem.https://gitlab.torproject.org/legacy/trac/-/issues/8239Hidden services should try harder to reuse their old intro points2020-06-13T14:46:24ZRoger DingledineHidden services should try harder to reuse their old intro pointsThe current hidden service behavior is that when Tor loses its intro circuits, it chooses new intro points and makes new circuits to them -- which means anybody who has the old hidden service descriptor is going to be introducing herself...The current hidden service behavior is that when Tor loses its intro circuits, it chooses new intro points and makes new circuits to them -- which means anybody who has the old hidden service descriptor is going to be introducing herself to the wrong intro points.
If our intro circuits close, but it was because our network failed and not because the intro points failed, we should reestablish new intro circuits to the *old* intro points.
Nathan wants this for running hidden services on Orbot, since Orbot users change networks (and thus lose existing circuits) quite often.
I expect the main tricky point to be distinguishing "network failed" from "intro point failed". I wonder if some of our CBT work is reusable here.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8243Getting the HSDir flag should require the Stable flag2020-06-13T14:57:52ZRoger DingledineGetting the HSDir flag should require the Stable flagWhen we invented the HSDir flag, our goal was to only use nodes for storing hidden service descriptors if they're likely enough to be around later. The question was solely around robustness: pick all but the nodes that have a good chance...When we invented the HSDir flag, our goal was to only use nodes for storing hidden service descriptors if they're likely enough to be around later. The question was solely around robustness: pick all but the nodes that have a good chance of going away while your hidden service descriptor is valid. We picked "has 25 hours of uptime" as what we hoped was an adequate threshold to stand in for the real question, which is "will likely remain online for the next hour".
But actually, there are security implications here too: an adversary who can control all six hsdir points for a hidden service can censor it (or, less bad, observe how many anonymous people access it).
So we should raise the bar for getting the HSDir flag, to raise the cost to an adversary who tries the Sybil the network in order to control lots of HSDir points.
That said, there's a contradiction here: the more restrictive we are about who gets the HSDir flag, the more valuable it becomes to get it. At the one extreme (our current choice), we give it to basically everybody, so you have to get a lot of them before your attack matters. At the other extreme, we could give it to our favorite 20 relays, and if we choose wisely then basically no adversaries will get the HSDir flag. What are the sweet spots in between?
(This ticket is inspired by rpw's upcoming Oakland paper)Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8742Byte history leaks information about local usage/hidden services2020-06-13T14:28:47ZTracByte history leaks information about local usage/hidden servicesNot sure if this is related to #516.
When acting as a relay, Tor seems to collect and report on *all* incoming and outgoing bandwidth. This data is then published publicly on Atlas, torstatus, or available for download.
As an example,...Not sure if this is related to #516.
When acting as a relay, Tor seems to collect and report on *all* incoming and outgoing bandwidth. This data is then published publicly on Atlas, torstatus, or available for download.
As an example, if you look at the monthly graph, it's pretty clear this relay become "something more than a relay" around the 7th of April:
https://atlas.torproject.org/#details/85617CE64344948B0BAC23CD4E22245F7F66C1C8
An attacker could use this data to determine if a relay hosts a hidden service (generally more bytes written than read), or if a user was actively browsing/downloading (more bytes read, generally) during a certain period of time. An active attacker could then create a large amount of traffic to a hidden service, perhaps creating a known pattern of high traffic followed by a period of little traffic, then review the byte history again and look for any relays that displayed a difference of read/write similar to the generated traffic. Having narrowed down the candidates, a DDOS of the relay would provide confirmation. Exposing clients would of course be far more difficult, as most probably do not run as a relay.
Possible solutions:
*By default, don't count any traffic to/from a hidden service. Could be enabled optionally in torrc... if someone really wanted it.
*By default, don't count any traffic beginning at tor's socks port. I can't think of any reason someone would want to enable this... but if there is a good argument for it, perhaps provide an option in torrc for this too.
*Most drastically... let a user opt out of reporting byte history completely. I'm guessing this is a "no go", since the stats are needed to help better network performance.
**Trac**:
**Username**: alphawolfTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/8864Hidden service: Suddenly the service does not respond to new connections (INT...2020-06-13T14:47:47ZTracHidden service: Suddenly the service does not respond to new connections (INTRODUCE2 cell on intro circ with no corresponding rend_intro_point_t)I am hosting a hidden service with tor on "Windows Server 2008 R2 Standard 64-bit".
The clients can connect to my service without problems after I start tor (my service is available as it should be).
After some time (it depends - it ca...I am hosting a hidden service with tor on "Windows Server 2008 R2 Standard 64-bit".
The clients can connect to my service without problems after I start tor (my service is available as it should be).
After some time (it depends - it can be 10 min, 30 min, up to 2 hours, but no longer than 2 hours) i get the following warning every few seconds:
[warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "<censored onion address>") with no corresponding rend_intro_point_t.
(see attached tor logs)
If i get this warnings, the service is not reachable for new connections, so i have to restart tor (existing connections seem to be working).
Tor on the client side shows no error message (it seems that the service is reachable for the client, but the client does not get a response from the service, otherwise a message like "hidden service is unavailable (try again later)" would appear - which is NOT the case)
After the restart the service is available again, but after a maximum of 2 hours the same problem appears again (service is not available for new clients).
I have nothing special in my torrc file (only the default file with HiddenServiceDir and HiddenServicePort additionally defined).
**Trac**:
**Username**: reiamTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8902Rumors that hidden services have trouble scaling to 100 concurrent connections2020-06-13T14:34:49ZRoger DingledineRumors that hidden services have trouble scaling to 100 concurrent connectionstomaw from freenode/oftc tells us the freenode hidden service doesn't work well once there are 100 users on it.
This is a great example of something a high-coverage perhaps-chutney-based test network could test (and then regression-test).tomaw from freenode/oftc tells us the freenode hidden service doesn't work well once there are 100 users on it.
This is a great example of something a high-coverage perhaps-chutney-based test network could test (and then regression-test).https://gitlab.torproject.org/legacy/trac/-/issues/11447Find a better value for MAX_REND_FAILURES2020-06-13T14:45:00ZNick MathewsonFind a better value for MAX_REND_FAILURESFor a while, MAX_REND_FAILURES was set to 30. That's clearly wrong; in #4241 we set it to 8. But is 8 the right value? We should investigate actual failure rates and pick a value that's more in tune with what we're actually seeing in t...For a while, MAX_REND_FAILURES was set to 30. That's clearly wrong; in #4241 we set it to 8. But is 8 the right value? We should investigate actual failure rates and pick a value that's more in tune with what we're actually seeing in the wild.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13085[patch] tor control connection event mask (32 bits) is too small for events (...2020-06-13T14:38:25Zteor[patch] tor control connection event mask (32 bits) is too small for events (33 events)In the tor git sources in early September 2014, the tor control connection event mask (or.h 1740):
struct control_connection_t { ... uint32_t event_mask; ... }
is too small to contain all of the 33 listed events (control.h 158):
#define...In the tor git sources in early September 2014, the tor control connection event mask (or.h 1740):
struct control_connection_t { ... uint32_t event_mask; ... }
is too small to contain all of the 33 listed events (control.h 158):
#define EVENT_MAX_ 0x0021
This makes the following code undefined for events 32 & 33 (control.c 585):
if (control_conn->event_mask & (1<<event)) {
The attached patch addresses this issue by making event_mask uint64_t, and casting to uint64_t before the left shift. It also updates the comment to note the upper bound of ((uint64_t)1)<<63.
As far as I can tell, the impact of this issue was to ignore or confuse with other event types:
#define EVENT_TRANSPORT_LAUNCHED 0x0020
#define EVENT_HS_DESC 0x0021
FYI - this error was discovered using a tor built with:
clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv
Version: tor 0.2.6.?-alpha git 54348201f7cce9c0c01e9d4835714a2fec55c67cTor: 0.2.6.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/13151OR address is in host order in INTRODUCE2 cell2020-06-13T14:38:37ZGeorge KadianakisOR address is in host order in INTRODUCE2 cellIt seems that the IP address of the RP is in host order in INTRODUCE2 cells, when it should be in network order. Here is the bad code https://gitweb.torproject.org/tor.git/blob/f8f0cb0443c0709454c9223f25266ec1b0c464b8:/src/or/rendclient....It seems that the IP address of the RP is in host order in INTRODUCE2 cells, when it should be in network order. Here is the bad code https://gitweb.torproject.org/tor.git/blob/f8f0cb0443c0709454c9223f25266ec1b0c464b8:/src/or/rendclient.c#l274 :
```
set_uint32(tmp+v3_shift+1, tor_addr_to_ipv4h(&extend_info->addr));
```
and here is the code that tries to parse it https://gitweb.torproject.org/tor.git/blob/f8f0cb0443c0709454c9223f25266ec1b0c464b8:/src/or/rendservice.c#l1785 :
```
tor_addr_from_ipv4n(&extend_info->addr, get_uint32(buf + 1));
```
Roger found that the bug was introduced in `960a0f0a`.
That said, rendezvous seems to work IRL so this bug is not so severe. Rendezvous is completed properly, because the HS probably uses the identity digest to map to a node.
I encountered that bug while fiddling with #12844 and trying to use a relay I just made as my RP. It didn't work.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13192Collect aggregate stats of total hidden service usage vs total exit usage in ...2020-06-13T14:41:11ZRoger DingledineCollect aggregate stats of total hidden service usage vs total exit usage in Tor networkI'd like to know what fraction of total Tor usage is hidden service usage, so we have a sense of whether hidden services matter now, and so we can track trends into the future.
For example, it would have been nice in August 2013 to have...I'd like to know what fraction of total Tor usage is hidden service usage, so we have a sense of whether hidden services matter now, and so we can track trends into the future.
For example, it would have been nice in August 2013 to have some metric of hidden service fraction that told us the spike in load and users had to do with hidden services.
Such statistics would also be useful to counter (or who knows, confirm) the analysts who say statements like "97% of Tor use is silk road".Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/13193Tag circuits locally by exit vs hidden-service, for stats2020-06-13T14:38:49ZRoger DingledineTag circuits locally by exit vs hidden-service, for statsIf we as a relay see a begin cell on a circuit, we know it's for exiting.
And if we see one of the various hidden service related cells on it, we know it's for hidden services.
And if we see an extend cell, we're a middle (i.e intermed...If we as a relay see a begin cell on a circuit, we know it's for exiting.
And if we see one of the various hidden service related cells on it, we know it's for hidden services.
And if we see an extend cell, we're a middle (i.e intermediary) hop in a circuit that terminates somewhere else. (assuming nobody uses the leaky pipe topology design, where you can exit from intermediary hops).
How many of each type of circuit do relays of various types handle?
And finally, what privacy risks are there to publishing aggregate ("total over past n seconds") statistics? for various values of n?
One approach to ameliorating the privacy question could be to discard circuits where the previous hop isn't a known relay. I think that's relays in the guard position, and relays in the middle-hop position for users who use bridges.https://gitlab.torproject.org/legacy/trac/-/issues/13206Write up walkthrough of control port events when accessing a hidden service2020-06-13T14:38:54ZRoger DingledineWrite up walkthrough of control port events when accessing a hidden serviceI've been helping some other SponsorR folks get up to speed on reading controller events when accessing a pile of hidden services. In theory the controller events should help you understand how far we got at reaching a hidden service whe...I've been helping some other SponsorR folks get up to speed on reading controller events when accessing a pile of hidden services. In theory the controller events should help you understand how far we got at reaching a hidden service when the connection fails. In practice it's a bit overwhelming.
I sat down in person to walk through the controlport output, but I should write it up as e.g. a wiki file so my explanation is usable by more people later too.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13208What's the average number of hsdir fetches before we get the hsdesc?2020-06-13T14:38:56ZRoger DingledineWhat's the average number of hsdir fetches before we get the hsdesc?Hidden services publish their hsdesc to six hsdir relays, once an hour.
Then relays come and go, changing the set of six that clients will compute when deciding which relay to fetch from.
Also, both hidden services and clients only fet...Hidden services publish their hsdesc to six hsdir relays, once an hour.
Then relays come and go, changing the set of six that clients will compute when deciding which relay to fetch from.
Also, both hidden services and clients only fetch a new consensus every 2-4 hours, so they will be perenially a few hours behind.
This could pretty easily result in a situation where (due to different knowledge on the hidden service's part) the hidden service doesn't publish to all six that it's "supposed" to, and (due to different knowledge on the client's part) the client doesn't pick from the same six that the hidden service published to, and (due to churn in the relays) the six that the hidden service published to might not remain the right six from a global perspective.
Realistically, do these skews matter?
We could imagine doing an experiment where we follow the client algorithm and find out the average number of fetches we do before we get an answer (or give up).Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13211Allow optimistic data on connections to hidden services2020-06-13T14:38:57ZRoger DingledineAllow optimistic data on connections to hidden servicesNow that #13153 is close to being resolved, it occurs to me that all supported (0.2.3.1-alpha and later) hidden services know what optimistic data is.
And by a stroke of luck (or who knows, maybe it was planned), it looks like the serve...Now that #13153 is close to being resolved, it occurs to me that all supported (0.2.3.1-alpha and later) hidden services know what optimistic data is.
And by a stroke of luck (or who knows, maybe it was planned), it looks like the server-side of the hidden service uses the same code as the exit relays do.
So with a few lines to let clients be willing to do it, we could cut out the initial round-trip to hidden service websites for each request from Tor Browser!Tor: 0.2.6.x-final