Tor source code file analysis-connetion_edge

Edge connections refer to connections used at both ends of the link, including AP connections and exit connections. EDGE connection is mainly used to provide services for an application connection. Therefore, the two edge connections are named application proxy connection and exit connection. These two connections mainly occur at both ends of the link, that is, the first hop of the link and the last hop of the link, which are used to receive application requests and process application requests respectively. EDGE connection also plays an important role in the TOR system. Therefore, this article briefly analyzes the source code file connection_edge.c for EDGE connection.

Because the EDGE connection is at both ends of the link, the transaction to be processed is much more complicated than the simple transfer and record of the intermediate node. There are many parts that I have not read in detail or find out their application needs, there must be many vague and inaccurate things here. Please forgive me.

0. Global Variables

/** A client-side struct to remember requests to rewrite addresses * to new addresses. these structs are stored in the hash table * "addressmap" below. * It can be seen that the addressmap global variable only exists on the client, and the TOR members of other identities do not use this global variable. ** there are 5 ways to set an address mapping: *-A mapaddress command from the Controller [permanent] *-An addressmap direve VE in the torrc [permanent] *-when a trackhostexits torrc directive is triggered [temporary] *-when a DNS resolve succeeds [temporary] *-when a DNS resolve fails [temporary] * visible here, in addition to configuring address ing in the configuration file, we mainly rely on DNS resolution to modify address mapping; ** when an addressmap request is made but one is already registered, * The new one is replaced only if the currently registered one has * No "new_address" (that is, it's in the process of DNS resolve ), * Or if the new one is permanent (expires = 0 or 1 ). ** (We overload the 'expires' field, using "0" for Mappings set via * the configuration file, "1" for Mappings set from the control * interface, and other values for DNS and trackhostexit mappings that can * expire .) ** a mapping may be 'wildcarded '. if "src_wildcard" is true, then * any address that ends with. followed by the key for this entry will * Get remapped by it. if "dst_wildcard" is also true, then only the * matching Suffix of such addresses will get replaced by new_address. */typedef struct {char * new_address; time_t expires; destination Source: 3; unsigned src_wildcard: 1; unsigned dst_wildcard: 1; short num_resolve_failures;} addressmap_entry_t; /** entry for mapping addresses to which virtual address we mapped them. */typedef struct {char * handle 4_address; char * hostname_address;} Handle address_entry_t;/** a hash table to store client-side address rewrite instructions. */static strmap_t * addressmap = NULL;/*** table mapping addresses to which virtual address, if any, we * assigned them. ** we maintain the following invariant: If [a, B] is in * virtaddress_reversemap, then B must be a virtual address, and [a, B] * must be in addressmap. we do not require that the converse hold: * if it fails, then we cocould end up mapping two virtual addresses to * the same address, which is no disaster. **/static strmap_t * virtaddress_reversemap = NULL;

The roles of the two global variables are unclear and need to be analyzed.

/* By default, we hand out 127.192.0.1 through 127.254.254.254. * These addresses should map to localhost, so even if the * application accidentally tried to connect to them directly (not * via Tor), it wouldn't get too far astray. * * These options are configured by parse_virtual_addr_network(). *//** Which network should we use for virtual IPv4 addresses?  Only the first * bits of this value are fixed. */static uint32_t virtual_addr_network = 0x7fc00000u;/** How many bits of <b>virtual_addr_network</b> are fixed? */static maskbits_t virtual_addr_netmask_bits = 10;/** What's the next virtual address we will hand out? */static uint32_t next_virtual_addr    = 0x7fc00000u;

The role of the variables is unclear.

1. General functions of AP and exit

Connection_edge_reached_eof --> connection_edge_end

Disconnect. If the identity is correct (AP), an end cell notification is sent to the corresponding egress node to close the data stream;

Connection_edge_process_inbuf

Manage connection transactions and data in the connection buffer in different situations;

Connection_edge_destroy --> connection_mark_unattached_ap (if the identity is AP)

Connection_edge_end_errno --> connection_edge_end

If the connection ends due to link disconnection or an errno, the connection is closed and a notification of stream termination is sent;

Connection_edge_flushed_some

Connection_edge_finished_flushing

Connection_edge_finished_connecting (mainly used when the identity is Exit)

Call related functions when the connection completes the buffer output or the lower-layer connection to finish the tail scan;

Connection_edge_is_rendezvous_stream

Connection_edge_compatible_with_circuit

Connection_edge_update_circuit_isolation

Circuit_clear_isolation

Some attributes of the connection are determined by the rendezvous subsystem and isolation flag;

2. AP processing functions

Connection_mark_unattached_ap

Connection_ap_about_to_close

Processing and closing before Ap connection is closed;

Connection_ap_handshake_send_begin

Connection_ap_handshake_send_resolve

The AP connection sends the Relay begin and relay resolve commands to the remote end to enable stream and address resolution;

Connection_ap_make_link

This function is generally used when the internal dir connection is related to the AP connection. This function creates an available AP connection and connects it to the Dir connection. available means that the AP connection finds the attached link circuit;

Connection_ap_handshake_socks_reply

Connection_ap_handshake_socks_resolved

Send related message to AP connection: Connection End message, address resolution success message;

Connection_ap_can_use_exit

Determine whether the egress node allows the corresponding AP to connect to the egress;

Connection_ap_expire_beginning

Connection_ap_attach_pending

Connection_ap_detach_retriable

Reconnect an AP connection with a request timeout, and allocate a link for the AP connection that cannot find the link again;

Connection_ap_fail_onehop

Notify all AP connections waiting for a node that cannot be connected;

Connection_ap_process_transparent --> connection_ap_rewrite_and_attach_if_allowed --> connection_ap_handshake_rewrite_and_attach

The functions used by transparent AP are not described in detail;

　　

3. Exit Processing Function

Connection_exit_about_to_close

Connection_exit_begin_conn --> connection_exit_connect

Connection_exit_begin_resolve

The above four functions include almost all the operations for the exit connection, mainly the connection establishment and external connection, as well as the address resolution and closure;

4. addressmap related processing functions (omitted)

Address_is_invalid_destination

Parse_virtual_addr_network

Parse_extended_hostname

Addressmap_init

Addressmap_clear_excluded_trackexithosts

Addressmap_clear_invalid_automaps

Addressmap_clean

Addressmap_clear_configured

Addressmap_clear_transient

Addressmap_free_all

Addressmap_rewrite

Addressmap_have_mapping

Addressmap_register

Addressmap_register_virtual_address

Addressmap_get_mappings

Client_dns_incr_failures

Client_dns_clear_failures

Client_dns_set_addressmap

5. Additional Functions (omitted)

Circuit_discard_optional_exit_enclaves

Get_pf_socket