Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:12:59Zhttps://gitlab.torproject.org/legacy/trac/-/issues/23311prop224: Spammy intro point logs in v22020-06-13T15:12:59ZGeorge Kadianakisprop224: Spammy intro point logs in v2With the #17242 branch, when I start an hsv2 service, there are good chances it will start spamming the logs like this:
```
Aug 21 14:59:02.000 [warn] Hidden service yfqspegde4a6pkt5 exceeded launch limit with 9 intro points in the last...With the #17242 branch, when I start an hsv2 service, there are good chances it will start spamming the logs like this:
```
Aug 21 14:59:02.000 [warn] Hidden service yfqspegde4a6pkt5 exceeded launch limit with 9 intro points in the last 31 seconds. Intro circuit launches are limited to 8 per 300 seconds.
Aug 21 14:59:02.000 [warn] Service configured in "/home/f/tmp/hsv2":
Aug 21 14:59:02.000 [warn] Intro point 0 at [scrubbed]: circuit is open
Aug 21 14:59:02.000 [warn] Intro point 1 at [scrubbed]: circuit is open
Aug 21 14:59:02.000 [warn] Intro point 2 at [scrubbed]: circuit is waiting to see how other guards perform
Aug 21 14:59:02.000 [warn] Intro point 3 at [scrubbed]: circuit is open
Aug 21 14:59:03.000 [warn] Hidden service yfqspegde4a6pkt5 exceeded launch limit with 9 intro points in the last 32 seconds. Intro circuit launches are limited to 8 per 300 seconds.
Aug 21 14:59:03.000 [warn] Service configured in "/home/f/tmp/hsv2":
Aug 21 14:59:03.000 [warn] Intro point 0 at [scrubbed]: circuit is open
Aug 21 14:59:03.000 [warn] Intro point 1 at [scrubbed]: circuit is open
Aug 21 14:59:03.000 [warn] Intro point 2 at [scrubbed]: circuit is open
Aug 21 14:59:04.000 [warn] Hidden service yfqspegde4a6pkt5 exceeded launch limit with 9 intro points in the last 33 seconds. Intro circuit launches are limited to 8 per 300 seconds.
Aug 21 14:59:04.000 [warn] Service configured in "/home/f/tmp/hsv2":
Aug 21 14:59:04.000 [warn] Intro point 0 at [scrubbed]: circuit is open
Aug 21 14:59:04.000 [warn] Intro point 1 at [scrubbed]: circuit is open
Aug 21 14:59:04.000 [warn] Intro point 2 at [scrubbed]: circuit is open
Aug 21 14:59:05.000 [warn] Hidden service yfqspegde4a6pkt5 exceeded launch limit with 9 intro points in the last 34 seconds. Intro circuit launches are limited to 8 per 300 seconds.
Aug 21 14:59:05.000 [warn] Service configured in "/home/f/tmp/hsv2":
Aug 21 14:59:05.000 [warn] Intro point 0 at [scrubbed]: circuit is open
Aug 21 14:59:05.000 [warn] Intro point 1 at [scrubbed]: circuit is open
Aug 21 14:59:05.000 [warn] Intro point 2 at [scrubbed]: circuit is open
Aug 21 14:59:06.000 [warn] Hidden service yfqspegde4a6pkt5 exceeded launch limit with 9 intro points in the last 35 seconds. Intro circuit launches are limited to 8 per 300 seconds.
Aug 21 14:59:06.000 [warn] Service configured in "/home/f/tmp/hsv2":
Aug 21 14:59:06.000 [warn] Intro point 0 at [scrubbed]: circuit is open
Aug 21 14:59:06.000 [warn] Intro point 1 at [scrubbed]: circuit is open
Aug 21 14:59:06.000 [warn] Intro point 2 at [scrubbed]: circuit is open
```
We need to figure out if this was caused by the prop224 patches and fix it if so.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23157prop224: Fix coverity reports generated by prop224 service merge (#20657)2020-06-13T15:12:35ZGeorge Kadianakisprop224: Fix coverity reports generated by prop224 service merge (#20657)Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22940prop224: HS revision counter should persist after service reboot2020-06-13T15:11:50ZGeorge Kadianakisprop224: HS revision counter should persist after service rebootWe currently have the following logic in the HSDir-side when accepting an HS descriptor:
```
if (cache_entry->plaintext_data->revision_counter >=
desc->plaintext_data->revision_counter) {
log_info(LD_REND, "Descriptor r...We currently have the following logic in the HSDir-side when accepting an HS descriptor:
```
if (cache_entry->plaintext_data->revision_counter >=
desc->plaintext_data->revision_counter) {
log_info(LD_REND, "Descriptor revision counter in our cache is "
"greater or equal than the one we received. "
"Rejecting!");
goto err;
}
```
Unfortunately, while HSes keep track of the revision counter in memory, they never save it on disk, so if the service reboots the Hs will lose track of the rev counter and publish descriptors with small counters that will get rejected by the HSDir.
We have brainstormed the following solutions for this:
a) Save the latest rev counter in the state file in a form like this:
`HidServRevCounter <service_pubkey> <rev_counter> <time_period_num>`
b) Set the rev counter to a value like `rounddown(time(NULL))` so that the HS always generates correct rev counters even without saving them on state.
However, wrt (b), since the quoted check above rejects equal rev counters the HS will have trouble uploading descriptors in the same hour. We could backport a fix that changes the check to 0.3.0 and then do this idea but that's kind of a PITA.
We are currently aiming for (a)Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22735prop224: HS desc overlap period func uses absolute times instead of slots2020-06-13T15:10:45ZGeorge Kadianakisprop224: HS desc overlap period func uses absolute times instead of slotsThe function that decides whether we are in HS desc overlap mode currently uses the following logic:
```
tor_gmtime_r(&consensus->valid_after, &valid_after_tm);
if (valid_after_tm.tm_hour > 0 && valid_after_tm.tm_hour < 12) {
ret...The function that decides whether we are in HS desc overlap mode currently uses the following logic:
```
tor_gmtime_r(&consensus->valid_after, &valid_after_tm);
if (valid_after_tm.tm_hour > 0 && valid_after_tm.tm_hour < 12) {
return 1;
}
```
While that logic is accurate wrt prop224 section 2.2.4, it's actually not a good idea since it uses absolute times, and it will fail to work as intended in the testnet.
We should refactor that logic to use the slot based system that we use for time periods and shared randomness, since semantically the HS desc overlap period is just the period between publishing a fresh SRV and starting the new time period.
We should also change the spec to reflect the new logic.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/21979prop224: Load and configure service2020-06-13T15:07:59ZDavid Gouletdgoulet@torproject.orgprop224: Load and configure serviceThis is a much bigger patch implementing a key feature of hidden service. Loading and configuring a service from the torrc file.
A new object is added which is `hs_service_t` representing a v3 service. The `hs_config.[ch]` files are int...This is a much bigger patch implementing a key feature of hidden service. Loading and configuring a service from the torrc file.
A new object is added which is `hs_service_t` representing a v3 service. The `hs_config.[ch]` files are introduced which loads the options and create an `hs_service_t` object out of it.
Like the legacy code, it goes in two steps. First, load the options and validate. Then, load/generate the keys if not in validate mode.
Some refactoring of the legacy code was needed in order to have a central entry point for the configuration of the HS options for both v2 and v3.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21888prop224: Groundwork for service implementation2020-06-13T15:07:39ZDavid Gouletdgoulet@torproject.orgprop224: Groundwork for service implementationThis is the parent ticket for a series of patches we want to merge upstream to lay the groundwork for the service implementation (#20657) in order to bring down the number of commits and size of that branch and making review less of a pa...This is the parent ticket for a series of patches we want to merge upstream to lay the groundwork for the service implementation (#20657) in order to bring down the number of commits and size of that branch and making review less of a pain.
I'll set this to 031 milestone if we have time to do it great! but ultimately this is only needed for 032 merge window so no biggy if we don't make it.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21008hs: Remove the introduction point private key material from hs_descriptor.h2020-06-13T15:04:36ZDavid Gouletdgoulet@torproject.orghs: Remove the introduction point private key material from hs_descriptor.hWe need to change the `curve25519_keypair_t` from `hs_desc_intro_point_t` to a public key only because both client and service will use that field.We need to change the `curve25519_keypair_t` from `hs_desc_intro_point_t` to a public key only because both client and service will use that field.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20656prop224: Tell protover about relay and hsdir support2020-06-13T15:03:21ZDavid Gouletdgoulet@torproject.orgprop224: Tell protover about relay and hsdir supportFor relay support in #17241 (parent ticket), we'll need to add version 4 to protover `HSIntro` so client/service can know which relay they can pick for introduction and version 2 to `HSDir`.For relay support in #17241 (parent ticket), we'll need to add version 4 to protover `HSIntro` so client/service can know which relay they can pick for introduction and version 2 to `HSDir`.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20571When we are really satisfied that it is right, tell protover.c about prop224 ...2020-06-13T15:02:57ZNick MathewsonWhen we are really satisfied that it is right, tell protover.c about prop224 HSDir supportThis will be trivial to do, but nontrivial to know when we should do it.
prop224-supporting hidden services and relays will need to know which Tor relays they should use to upload and download the new kind of descriptors. So, they shoul...This will be trivial to do, but nontrivial to know when we should do it.
prop224-supporting hidden services and relays will need to know which Tor relays they should use to upload and download the new kind of descriptors. So, they should use the preferred mechanism for it.
As of proposal 264, that's protocol subversions.
We should only advertise support for this server-side once we're pretty sure we aren't changing the server side any more.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20524Revise initial descriptor upload behavior for onion services2020-06-13T15:02:40ZtwimRevise initial descriptor upload behavior for onion servicesAccording to `rend-spec.txt`:
```
When uploading descriptors, the hidden service needs to make sure that
descriptors for different clients are not uploaded at the same time (cf.
Section 1.1) which is also a limiting factor for t...According to `rend-spec.txt`:
```
When uploading descriptors, the hidden service needs to make sure that
descriptors for different clients are not uploaded at the same time (cf.
Section 1.1) which is also a limiting factor for the number of clients.
```
At the moment it's unclear how it should be implemented and why.
* What is the threat model here?
* How exactly descriptors should be uploaded?
* In what range delays should be set?
* How this will work along with absent delays after #20082?Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/18054prop224: Decide how to proceed with torrc options2020-06-13T14:53:26ZDavid Gouletdgoulet@torproject.orgprop224: Decide how to proceed with torrc optionsWith next-gen HS, we'll have both new and legacy system running in parallel. However, we should encourage as much as possible the adoption of the new system when setting up a new hidden service.
From a torrc perspective, we should proba...With next-gen HS, we'll have both new and legacy system running in parallel. However, we should encourage as much as possible the adoption of the new system when setting up a new hidden service.
From a torrc perspective, we should probably use the same options as we have now but making tor code a bit more smarter when parsing them. One idea would be to add an option that indicates if the user wants the legacy protocol or not:
Something that could look like:
```
HiddenServiceLegacy 1
HiddenServiceDir <PATH>
HiddenServicePort ...
```
And `HiddenServiceLegacy` by default would be 0. This option should be deprecated over time.
Another possibility is NOT having this config option and only if "private_key" file exists in the `HiddenServiceDir` and it's `RSA1024`, we switch to legacy. Without it, we go next-gen. So in other words, we DO NOT let a user setup a legacy HS unless she has a key for it placed in the HS directory. This will allow current HS setup to still work after upgrade and not make operators add an extra option.
Basically, the key type would be our heuristic to switch from legacy to next-gen.Tor: 0.3.1.x-final