Opened 3 years ago

Last modified 4 months ago

#12500 new enhancement

Add an option to upload hidden service descriptors some time after startup

Reported by: andrea Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, easy, traffic-analysis security
Cc: special Actual Points:
Parent ID: Points:
Reviewer: teor Sponsor: SponsorR-can

Description

#4243 is bullshit; it doesn't seem to describe the actual behavior, but what it describes would be the correct thing if it were what we did. We should investigate this and render it sane.

Descriptor upload happens from rend_consider_services_upload(time_t now) - some things to consider:

1.) Where does now come from? Is this another thing that should use CLOCK_MONOTONIC when available?

2.) Looks like we correctly randomize the upload time for new descriptors:

3239     if (!service->next_upload_time) { /* never been uploaded yet */
3240       /* The fixed lower bound of 30 seconds ensures that the descriptor
3241        * is stable before being published. See comment below. */
3242       service->next_upload_time =
3243         now + 30 + crypto_rand_int(2*rendpostperiod);
3244     }

...but we make our decision on what to upload based on next_upload_time or desc_is_dirty:

3245     if (service->next_upload_time < now ||
3246         (service->desc_is_dirty &&
3247          service->desc_is_dirty < now-30)) {
3248       /* if it's time, or if the directory servers have a wrong service
3249        * descriptor and ours has been stable for 30 seconds, upload a
3250        * new one of each format. */
3251       rend_service_update_descriptor(service);
3252       upload_service_descriptor(service);
3253     }

We should look at how desc_is_dirty gets set and make sure this doesn't cause newly created HS descriptors to always be immediately uploaded.

Child Tickets

Change History (23)

comment:1 Changed 3 years ago by special

Cc: special added

comment:2 in reply to:  description Changed 3 years ago by sysrqb

Keywords: tor-hs added

This is actually a reasonably large problem. When a hidden service is first started it will always upload its descriptor 30 seconds later.

Replying to andrea:

Descriptor upload happens from rend_consider_services_upload(time_t now) - some things to consider:
1.) Where does now come from? Is this another thing that should use CLOCK_MONOTONIC when available?

For reference, now comes from the top of second_elapsed_callback(). CLOCK_MONOTONIC would likely be a good thing to use, but the "forcing the clock to jump sufficiently far into the future" is an equally effective attack.

3245     if (service->next_upload_time < now ||
3246         (service->desc_is_dirty &&
3247          service->desc_is_dirty < now-30)) {
3248       /* if it's time, or if the directory servers have a wrong service
3249        * descriptor and ours has been stable for 30 seconds, upload a
3250        * new one of each format. */
3251       rend_service_update_descriptor(service);
3252       upload_service_descriptor(service);
3253     }

We should look at how desc_is_dirty gets set and make sure this doesn't cause newly created HS descriptors to always be immediately uploaded.

We set it as dirty when we add or remove intro points. This includes when we first add the hidden service. If we want to be safe here we should simply remove the "stable for 30 seconds" criterion and leave the 0 < x < 2*rendpostperiod. On the other hand, as rransom mentions in #4243, clients will not be as happy about waiting up to 2 hours before the descriptor is published. They can decrease the value of RendPostPeriod, if this is a problem, though.

comment:3 Changed 3 years ago by special

On the other hand, as rransom mentions in #4243, clients will not be as happy about waiting up to 2 hours before the descriptor is published. They can decrease the value of RendPostPeriod, if this is a problem, though.

I think most hidden service operators would be confused by an up-to-two hour delay. I understand the reason behind it, but it seems unacceptably long for most cases. I expect a lot of "why doesn't my hidden service work?!", and a lot of people applying the workaround they find on a search engine.

Decreasing RendPostPeriod is not a valid workaround, particularly for software that relies on the service being published interactively. I think a separate option for that is required.

comment:4 Changed 3 years ago by dgoulet

Cc: dgoulet added

comment:5 Changed 3 years ago by arma

Also see #13483. I think publishing your hidden service very soon after starting up is what users expect.

comment:6 Changed 3 years ago by dgoulet

For starter, that would badly break ricochet IM usability if your body can take up to two hours to show up :) or onion share also...

I advocate to modify this to "Won't fix" maybe?

comment:7 Changed 3 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: unspecified

Make it an option, perhaps. But it doesn't need to go into 0.2.6.

comment:8 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.7.x-final

Worth looking at during 0.2.7 triage IMO

comment:9 Changed 3 years ago by nickm

Status: newassigned

comment:10 Changed 3 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???
Summary: Slay hidden service upload time dragonsAdd an option to upload hidden service descriptors some time after startup

comment:11 Changed 23 months ago by dgoulet

Cc: dgoulet removed
Keywords: easy added; 026-triaged-1 026-deferrable removed
Points: small
Severity: Normal
Sponsor: SponsorR
Type: defectenhancement

comment:12 Changed 21 months ago by dgoulet

Sponsor: SponsorRSponsorR-can

Move those from SponsorR to SponsorR-can.

comment:13 Changed 15 months ago by teor

Parent ID: #20082

#20082 is a patch for making the initial 30s delay shorter, this is related

comment:14 Changed 14 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.0.x-final
Resolution: fixed
Reviewer: teor
Status: assignedclosed

This bug is fixed in #20082 by removing the offending code, #20262 will add back in a delay if research discovers it is actually useful.

comment:15 Changed 14 months ago by teor

Version: Tor: 0.2.5.5-alphaTor: unspecified

comment:16 Changed 14 months ago by teor

(bugfix on commit 4b76fe8 in 0.0.9pre6)

comment:17 Changed 14 months ago by dgoulet

Milestone: Tor: 0.3.0.x-finalTor: 0.2.???
Parent ID: #20082
Resolution: fixed
Status: closedreopened
Version: Tor: unspecified

#20082 won't add an option after all. So we should still keep this open as maybe one day we will want the option to delay descriptor upload. I'm also un-parenting the ticket so it can be free! :)

comment:18 Changed 13 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:19 Changed 12 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:20 Changed 7 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:21 Changed 7 months ago by dgoulet

Parent ID: #20657
Points: small
Status: reopenednew

I do thing adding an option in legacy HS is not a good idea but we should consider for prop224 (#20657).

comment:22 Changed 6 months ago by nickm

Keywords: traffic-analysis security added

comment:23 Changed 4 months ago by dgoulet

Parent ID: #20657

prop224 hasn't implemented that for 032.

Note: See TracTickets for help on using tickets.