Opened 6 weeks ago

Last modified 5 weeks ago

#27446 new defect

Vague 'see log' response when HS creation fails

Reported by: atagar Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Minor Keywords: tor-hs
Cc: asn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Hi lovely network team folks. Few days ago Stem's integ tests started failing with...

======================================================================
ERROR: test_hidden_services_conf
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/atagar/Desktop/stem/test/require.py", line 58, in wrapped
    return func(self, *args, **kwargs)
  File "/home/atagar/Desktop/stem/test/integ/control/controller.py", line 458, in test_hidden_services_conf
    controller.set_hidden_service_conf(initialconf)
  File "/home/atagar/Desktop/stem/stem/control.py", line 2614, in set_hidden_service_conf
    self.set_options(hidden_service_options)
  File "/home/atagar/Desktop/stem/stem/control.py", line 2451, in set_options
    raise stem.InvalidRequest(response.code, response.message)
InvalidRequest: Unacceptable option value: Failed to configure rendezvous options. See logs for details.

----------------------------------------------------------------------

Narrowing this down to a telnet repro with the present tor head (commit fd994f5) gives the following...

% cat ~/.tor/torrc
SocksPort 0
ControlPort 9051
ExitPolicy reject *:*


% telnet localhost 9051

AUTHENTICATE
250 OK

SETCONF HiddenServiceDir="/tmp/test_hidden_service" HiddenServicePort="8030 127.0.0.1:8030" HiddenServiceAuthorizeClient="stealth a, b"
513 Unacceptable option value: Failed to configure rendezvous options. See logs for details.

Error responses should not cite log output. That aside, here's what logs say...

Sep 04 10:47:19.000 [warn] Hidden service option HiddenServiceAuthorizeClient is incompatible with version 3 of service in /tmp/test_hidden_service
Sep 04 10:47:19.000 [warn] Controller gave us config lines that didn't validate: Failed to configure rendezvous options. See logs for details.

My understanding is that hidden services that are configured through the torrc are v2, whereas ephemeral hidden services are v2 or v3 based on the key type (RSA1024 for v2 and ED25519-V3 for v3).

Seems this changed and now torrcs create v3 rather than v2 services? Is this intentional? Since this breaks backward compatibility I assume this means we're dropping v2 hidden services in the next tor release?

Child Tickets

Change History (7)

comment:1 Changed 6 weeks ago by nickm

Cc: asn dgoulet added
Milestone: Tor: 0.3.5.x-final

comment:2 Changed 6 weeks ago by dgoulet

Cc: dgoulet removed
Keywords: tor-hs added
Status: newneeds_information

Yes we recently made it that the default version is now 3 so one has to explicitly put HiddenServiceVersion 2 starting on 0.3.5 (not yet released).

To answer your question now, yes it breaks backward compatibility for *new* services. Old services, tor will detect the version by looking at the key material and if it sees an RSA key in the appropriate file, then your service will be a v2.

The idea is indeed long term to phase out v2. Hope this answers your question?

comment:3 Changed 6 weeks ago by atagar

Status: needs_informationnew

Thanks David! Since this is intended I'll adjust Stem to match. Off the top of my head there's a few follow-up actions here...

  • [Tor] Could you please clarify the above error response? Since we're breaking backward compatibility we should be very clear in the response what is going on. In particular when users provide v2 HS arguments we should provide a response such as...

"Version 2 hidden services are deprecated, and this method now creates v3 hidden services by default which is incompatible with the X argument. Please see Y for our documentation on v3 hidden services, and include 'HiddenServiceVersion 2' if you would like to explicitly create a version 2 hidden service anyway."

  • [Stem] I'll change our Controller's create_hidden_service() method to include 'HiddenServiceVersion 2' in tor 0.3.5 and higher.
  • [Stem] Stepping back I should rethink Stem's hidden service API. I'll probably wait until these mature more. In particular I'd like to see #25918 so we're consistent on the naming, and clarification on what I should do with HS descriptor parsing (should I simply remove v2 HS descriptor methods without a v3 counterpart?).

comment:4 Changed 6 weeks ago by atagar

There we go. Made Stem a little smarter in that it now specifies v2 HS creation when creating a service with any v2-only options. Tests now pass...

https://gitweb.torproject.org/stem.git/commit/?id=b09fa11

This can be resolved once tor's error response is clarified.

Thanks for the help, David!

comment:5 in reply to:  3 Changed 5 weeks ago by dgoulet

Replying to atagar:

  • [Tor] Could you please clarify the above error response? Since we're breaking backward compatibility we should be very clear in the response what is going on. In particular when users provide v2 HS arguments we should provide a response such as...

"Version 2 hidden services are deprecated, and this method now creates v3 hidden services by default which is incompatible with the X argument. Please see Y for our documentation on v3 hidden services, and include 'HiddenServiceVersion 2' if you would like to explicitly create a version 2 hidden service anyway."

So this is a "fun" one ... The reported error is really a "generic" one because there are so many ways you can fail configuration that we log the error and then provide that generic failure message at in the end.

In other words, we would need a major refactoring to be able to tell the user if the error was related to a v2 option used with v3 for instance. Which is probably why there is this "see logs for details"...

I'm not sure how we can fix that so users on the control port at least get something meaningful?

comment:6 Changed 5 weeks ago by atagar

Priority: MediumLow
Severity: NormalMinor
Summary: HS creation via SETCONF changed from v2 to v3Vague 'see log' response when HS creation fails

Thanks for looking into this, David! More precise error output would be helpful but if it's a pita I don't mind if we defer on this. We shouldn't resolve this until it's fixed but adjusting the ticket title and dropping the priority.

comment:7 Changed 5 weeks ago by dgoulet

Milestone: Tor: 0.3.5.x-finalTor: unspecified

Moving to Unspecified.

To try to go forward, I wonder here if there is a world where we would want to report any configuration error on the control port instead of only the logs? The entire HS configuration process can go through a LOT of errors...

Note: See TracTickets for help on using tickets.