Option to skip authorization verification in INTRODUCE2 cell

[donncha]

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.

[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?

[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.

[teor]

Milestone renamed

[nickm]

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

[nickm]

Remove an old triaging keyword.

[traumschule]

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.)