* Check consistency between the two single onion torrc options
* Use the more relevant option each time we check for single onion mode
* Clarify log messages
* Clarify comments
* Otherwise, no behaviour change
Add experimental OnionServiceSingleHopMode and
OnionServiceNonAnonymousMode options. When both are set to 1, every
hidden service on a tor instance becomes a non-anonymous Single Onion
Service. Single Onions make one-hop (direct) connections to their
introduction and renzedvous points. One-hop circuits make Single Onion
servers easily locatable, but clients remain location-anonymous.
This is compatible with the existing hidden service implementation, and
works on the current tor network without any changes to older relays or
clients.
Implements proposal #260, completes ticket #17178. Patch by teor & asn.
squash! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! Implement Prop #260: Single Onion Services
Redesign single onion service poisoning.
When in OnionServiceSingleHopMode, each hidden service key is poisoned
(marked as non-anonymous) on creation by creating a poison file in the
hidden service directory.
Existing keys are considered non-anonymous if this file exists, and
anonymous if it does not.
Tor refuses to launch in OnionServiceSingleHopMode if any existing keys
are anonymous. Similarly, it refuses to launch in anonymous client mode
if any existing keys are non-anonymous.
Rewrite the unit tests to match and be more comprehensive.
Adds a bonus unit test for rend_service_load_all_keys().
Tor stores client authorization cookies in two slightly different forms.
The service's client_keys file has the standard base64-encoded cookie,
including two chars of padding. The hostname file and the client remove
the two padding chars, and store an auth type flag in the unused bits.
The distinction makes no sense. Refactor all decoding to use the same
function, which will accept either form, and use a helper function for
encoding the truncated format.
When we made HidServDirectoryV2 always 1, we removed the situation
where a relay could choose not to be an HSDir. Now simplify the
rest of the code to reflect this decision.
(We have to remove two apparently unrelated free() calls in the unit
tests, since they used to free stuff that we created as a side effect
of calling router_get_my_routerinfo(), and now we no longer call that.)
This simplifies relay behavior, because the relay offers the hsdir
functionality independent of whether the directory authorities have
decided this relay is suitable for clients to use yet.
Implements ticket 18332.
Including the replica number in the HS_DESC CREATED event provides
more context to a control port client. The replica allows clients
to more easily identify each replicated descriptor from the
independantly output control events.
Service descriptors are now generated regardless of the the
PublishHidServDescriptors option. The generated descriptors are stored
in the service descriptor cache.
The PublishHidServDescriptors = 1 option now prevents descriptor
publication to the HSDirs rather than descriptor generation.
Every functions and objects that are used for hidden service descriptor
caches are moved to rendcache.{c|h}.
This commit does NOT change anything, just moving code around.
Fixes#16399
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
This reverts commit 9407040c59.
Small fix, "e->received" had to be removed since that variable doesn't exist
anymore.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
For FAILED and RECEIVED action of the HS_DESC event, we now sends back the
descriptor ID at the end like specified in the control-spec section 4.1.25.
Fixes#15881
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Ground works for fixing #15816. This adds the rend_data_create() function in
order to have a single place where we initialize that data structure.
Furthermore, an array of descriptor IDs is added (one per replica) so we can
keep a copy of the current id in the object. It will be used to purge the
last hid serv request cache using those descriptor IDs. When they change,
they will be replaced and the old ones will be purged from the cache.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
The HS_DESC event was using rend_data_t from the dir connection to reply the
onion address and authentication type. With the new HSFETCH command, it's
now possible to fetch a descriptor only using the descriptor id thus
resulting in not having an onion address in any HS_DESC event.
This patch removes rend_query from the hs desc control functions and replace
it by an onion address string and an auth type.
On a successful fetch, the service id is taken from the fetched descriptor.
For that, an extra parameter is added to "store as a client" function that
contains the cache entry stored.
This will make the control event functions scale more easily over time if
other values not present in rend_data_t are needed since the rend_data from
the dir connection might not contained everything we need.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Big refactor of the HS client descriptor fetch functionnality. This allows
to fetch an HS descriptor using only a descriptor ID. Furthermore, it's also
possible to provide a list of HSDir(s) now that are used instead of the
automatically choosen one.
The approach taken was to add a descriptor_id field to the rend_data_t
structure so it can be used, if available, by the HS client. The onion
address field however has priority over it that is if both are set, the
onion address is used to fetch the descriptor.
A new public function is introduced called rend_client_fetch_v2_desc(...)
that does NOT lookup the client cache before fetching and can take a list of
HSDirs as a parameter.
The HSFETCH control command now uses this new function thus making it work
and final.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
The rend-spec.txt document doesn't specify this extra newline. Furthermore,
this is the only descryptor type that contains one. Client and HSDir without
this patch still work perfectly since the HS descriptor parsing doesn't
expect a newline at the end.
Fixes#15296
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Here is why:
1) v0 descriptors are deprecated since 0.2.2.1 and not suppose to be alive
in the network anymore. This function should only serve v2 version for now
as the default.
2) It should return different error code depending on what's the actual
error is. Right now, there is no distinction between a cache entry not found
and an invalid query.
3) This function should NOT test if the intro points are usable or not. This
adds some load on a function that should be "O(1)" and do one job.
Furthermore, multiple callsites actually already test that doing twice the
job...
4) While adding control event, it would be useful to be able to lookup a
cache entry without having it checking the intro points. There are also
places in the code that do want to lookup the cache entry without doing
that.
Fixes#14391
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
This fixes a bug where we'd fetch different replicas of the same
descriptor for a down hidden service over and over, until we got lucky
and fetched the same replica twice in a row.
Fixes bug 14219; bugfix on 0.2.0.10-alpha.
(Patch from Roger; commit message and changes file by Nick.)
Have clients and authorities both have new behavior, since the
fix for bug 11243 has gone in. But make clients still accept
accept old bogus HSDir descriptors, to avoid fingerprinting trickery.
Fixes bug 9286.
The two statistics are:
1. number of RELAY cells observed on successfully established
rendezvous circuits; and
2. number of .onion addresses observed as hidden-service
directory.
Both statistics are accumulated over 24 hours, obfuscated by rounding
up to the next multiple of a given number and adding random noise,
and written to local file stats/hidserv-stats.
Notably, no statistics will be gathered on clients or services, but
only on relays.
