Opened 4 years ago

Last modified 5 months ago

#15991 new enhancement

Option to skip authorization verification in INTRODUCE2 cell

Reported by: donncha Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, needs-design, hs-auth
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor clients include an authorization cookie in the INTRODUCE2 cell when accessing a hidden service configured with client authorization. The service verifies the INTRODUCE2 cells and denies request which don't include (a valid) authorization. I'd like to be able to use stealth authorization as a means of distributing introduction point information in a private way. I'd like for clients who eventually receive the decrypted introduction point data to be able to connect to the hidden service without needing to know the original authorization cookie.

This would be useful in my Summer of Privacy project to distribute IP data in a private way while allowing clients to connect as normal (without authorization) to a published descriptor containing those introduction points.

I can also see a use case situation where a service would like to distribute stealth authorization introduction points to a client outside of the HSDir system by using some other form of client authorization (web of trust, captcha, etc.).

I'd propose a 'HiddenServiceNoAuthorizationVerify' option to allow service operators to disable authorization verification of a per service basis. I think Tor should provide a suitable warning on start up to ensure operators are aware of the potential consequences of enabling the option.

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
HiddenServiceAuthorizeClient stealth user
HiddenServiceNoAuthorizationVerify 0

If people think this option is a reasonable idea, I can start writing a patch for the feature.

Child Tickets

Change History (9)

comment:1 Changed 4 years ago by asn

FWIW, this will be fixed when/if #8106 happens.

What attacks are you afraid of, that make you want to hide the IPs of your HS nodes?

comment:2 Changed 4 years ago by donncha

Thanks for the feedback. I'm not really aware of the risks arising from publicly publishing a HS instance's IPs. It could allow an attacker running HSDirs to determine that the HS is using (somethingl ike) OnionBalance, if they see that the same IP is incorporated in multiple descriptors.

Is it a big problem is an attacker can discover that a HS is using OnionBalance? Looking at the data in #15513, I think it might be difficult to select IPs from multiple instances in a way that wouldn't be distinguishable from the behaviour of a standard HS.

At the moment, I'm planning to implement #3521, it should allow the management service to more reliably fetch up-to-date descriptors from the HS instances when the IPs change. It should also avoid the need for this ticket.

comment:3 Changed 3 years ago by teor

Milestone: Tor: 0.2.???

comment:4 Changed 2 years ago by teor

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

Milestone renamed

comment:5 Changed 2 years 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:6 Changed 22 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 22 months ago by dgoulet

Cc: dgoulet removed
Keywords: tor-hs added; hs removed
Severity: Normal

comment:8 Changed 21 months ago by nickm

Keywords: needs-design added

comment:9 Changed 5 months ago by traumschule

Keywords: hs-auth added

Let onion service authorization related tickets know of each other.

https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n615

[TODO: Also specify stealth client authorization.]
(NOTE: client authorization is not implemented as of 0.3.2.1-alpha.)

Note: See TracTickets for help on using tickets.