Rendezvous Point (RP) & Introduction Point (IP), code question

Question

# grep -n onion_address src/or/rendservice.c 
567:                 oc->rend_data->onion_address);
1373:  strlcpy(launched->rend_data->onion_address, service->service_id,
1374:          sizeof(launched->rend_data->onion_address));
2364:  strlcpy(launched->rend_data->onion_address, service->service_id,
2365:          sizeof(launched->rend_data->onion_address));
2387:          !rend_cmp_service_ids(query, oc->rend_data->onion_address))
2733:  serviceid = circ->rend_data->onion_address;

Are this onion addresses mine or this addresses are belonging to services which want me to be rend service for him? What exactly oc-> and launched->rend_data-> means?

I add this option to my torrc:

SafeLogging 0 

I'm looking for onion addresses that use my relay as rendezvous. I can not understand how any hidden service may use my relay as rendezvous, without a notice to me about the ID ( sha256.onion domain address ). I have read a lot of Tor's papers, very faster, and dive deep into code. I'm open for myself that there is another type of middle node - IP ( Introduction Point ).

Could you explain to me precisely, and step by step, which function catch what and how from hidden service. Thereafter, How Alice come to me with only sha256.onion domain? She ask me for the IP ( Introduction Point ). I don't know about this ID ( sha256.onion ). But if Hidden Service ( Bob ) use exactly my V2Dir, I can provide her with 3 IP?

Raw code, better patch like:

log_info(LD_REND, "Alice ask for %s hidden service",  oc->rend_data->onion_address );

Or, Bob's part.

*** 1373,1378 ****
--- 1373,1380 ----
    strlcpy(launched->rend_data->onion_address, service->service_id,
            sizeof(launched->rend_data->onion_address));

+   log_info(LD_REND, "Bob use this relay as RP for %s", launched->rend_data->onion_address );
+ 
    launched->build_state->service_pending_final_cpath_ref =
      tor_malloc_zero(sizeof(crypt_path_reference_t));
    launched->build_state->service_pending_final_cpath_ref->refcount = 1;

Will be great !

Cheers !

Answer 1

What exactly oc-> and launched->rend_data-> means?

• both are pointers used by the HS
• the contents of rendservice.c refer to 'The hidden-service side of rendezvous functionality'
• what they mean depends on the context of use

int rend_config_services (const or_options_t *, int)

• for registering a HS
• oc is a pointer to the intro point circuit for the HS being registered

static int count_established_intro_points(const char *)

• oc is a pointer to the intro point circuit to the HS represented by the string

int rend_service_introduce (origin_circuit_t *, const uint8_t *, size_t)

• launched is a pointer to the rendezvous point circuit
• (aside: which is also known as oldcirc/newcirc if failures occur)

static int rend_service_launch_establish_intro(rend_service_t *, rend_intro_point_t *)

• launched is a pointer to the intro point circuit

I'm looking for onion addresses that use my relay as rendezvous.

I see this part of your question hasn't yet been fully clarified so I will try.

SafeLogging will replace references in your log of [scrubbed] with the actual address. This doesn't include the onion address. I recommend you start with the following, code-free, and visual, guide to hidden service operation.

In particular look at the end of step (3). "the client also creates a circuit to another randomly picked relay and asks it to act as rendezvous point by telling it a one-time secret"

Later, in step (5), you see the one-time secret again, "The (hidden) service creates a circuit to the rendezvous point and sends the one-time secret to it in a rendezvous message". So, the rendezvous point (you, in this example) connects the already established client-circuit to the newly formed HS-circuit by using this shared secret. In this manner you never get to see which onion address you're acting as a rendezvous for. You only have the one-time secret. The one-time secret allows you to identify a client-service relationship for acting as the rendezvous point. If you're interested this one-time secret is part of the rend_data_t structure. The circuit pointers I mentioned above contain this structure as a member. This structure is allocated dynamically so it is, itself, a pointer to it's members (which is why you see oc->rend_data-> and launched->rend_data->). You can locate this structure in the source file or.h.

Raw code, better patch like ...

I hope I've clarified why this type of logging doesn't occur. It would make hidden services insecure. Maybe you mean well but someone certainly would exploit this information.

Finally, if you prefer to dig through the code for your step-by-step, you can use gdb. You can watch the function call flow for the various states of hidden service operation, service, client, mid.

1. get/build the debug version of tor including debug symbols

   • This looks like a good place to start. You could also find assistance with this on the mailing list tor-dev.

2. allow debugger attachment by adding to your torrc

   • DisableDebuggerAttachment 0

3. get the pid by adding to your torrc

   • PidFile FILE

4. start up the tor process your usual way and locate it's pid from FILE or by using ps -A in a terminal

5. attach to the tor process using it's pid, gdb -p pid
6. now you can (amoung other things) force gdb to break on particular functions of interest or all functions in a file
   • rbreak some_fn0
   • break some_fn1
   • rbreak some_source_file.c:.*

I hope that clears things up for you.

-- leeroy

Answer 2

Just a quick answer without diving into the code:

A Rendezvous Point will not be able to notice which Relay / Client is using it. It will only get the rendezvous cookie and, as always, knows the last Relay in the circuit which is connecting to it. So, as far as I can tell, you won't be able to find this sha256.onion domain.

A more detailed answer and some sources will properly follow in the next days...