[tor-bugs] #6465 [Tor Relay]: Build abstraction layer around TLS

[Tor Bug Tracker & Wiki]

#6465: Build abstraction layer around TLS
-----------------------+----------------------------------------------------
 Reporter:  andrea     |          Owner:  andrea            
     Type:  project    |         Status:  new               
 Priority:  major      |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor Relay  |        Version:  Tor: unspecified  
 Keywords:             |         Parent:                    
   Points:             |   Actualpoints:                    
-----------------------+----------------------------------------------------

Comment(by andrea):

 For my own reference, here is a list of all places outside connection_or.c
 that call into it, with a brief note on what will need to be done to it:

 circuitbuild.c:1956 calls connection_or_get_for_extend()
 circuitbuild.c:1971 calls connection_or_connect()
   * These are in circuit_handle_first_hop(), will need to be replaced with
     channel_*() calls.

 circuitbuild.c:2469 calls connection_or_get_for_extend()
 circuitbuild.c:2489 calls connection_or_connect()
   * These are in circuit_extend(), similar to above

 circuitbuild.c:2853 calls connection_or_nonopen_was_started_here()
   * Looks like it uses this to test whether a connection was locally
 initiated,
     to decide whether to call router_orport_found_reachable().  I'll have
 to
     figure out something analogous for channelized circuits I guess.

 circuitbuild.c:5537 calls connection_or_set_bad_connections()
   * This is in entries_retry_helper() and involved in declaring a node
 down;
     this will need to be changed to an abstract channel level (not per
 channel
     subclass, since a node could speak multiple transports and is
 presumably
     down for all of them) mechanism.

 circuitlist.c:927 calls connection_or_unlink_all_active_circs()
   * This is circuit_unlink_all_from_or_conn(), which will need to be
 replaced
     with circuit_unlink_all_from_channel()

 circuitlist.c:1310 calls connection_or_send_destroy()
 circuitlist.c:1337 calls connection_or_send_destroy()
   * These are both in _circuit_mark_for_close();
 connection_or_send_destroy()
     will need to be replaced with channel_send_destroy()

 command.c:368 calls connection_or_send_destroy()
   * This is when processing a CREATE cell while shutting down; will need
 to
     replace with channel_send_destroy() and make sure these
 command_process_*
     functions get called from the channel receive callback mechanism.

 command.c:380 calls connection_or_send_destroy()
 command.c:393 calls connection_or_send_destroy()
   * Other CREATE-denial cases similar to above

 command.c:642 calls connection_or_nonopen_was_started_here()
   * enter_v3_handshake_with_cell(): how are we going to handle this?  TLS
     handshakes need to live below the channel layer but cell handling is
     above.

 command.c:672 calls connection_or_nonopen_was_started_here()
 command.c:732 calls connection_or_send_netinfo()
 command.c:767 calls connection_or_send_versions()
 command.c:774 calls connection_or_send_certs_cell()
 command.c:781 calls connection_or_send_auth_challenge_cell()
 command.c:788 calls connection_or_send_netinfo()
   * command_process_versions_cell() this will have to get called by the
     channel callback mechanism handling received cells.  The
     connection_or_send_netinfo() call will need to become something like
     channel_send_netinfo().  Similar for other connection_or_send_*
     functions.

 command.c:843 calls connection_or_set_circid_type()
 command.c:845 calls connection_or_init_conn_from_address()
 command.c:926 calls connection_or_set_state_open()
   * These are in command_process_netinfo_cell(); need to figure out how
 this
     bookkeeping stuff works; the state probably needs to become per
 channel
     rather than per or_connection_t.

 command.c:1073 calls connection_or_set_circid_type()
 command.c:1077 calls connection_or_client_learned_peer_id()
 command.c:1116 calls connection_or_send_netinfo()
   * These are all in command_process_certs_cell(); similar comments to
 above.

 command.c:1193 calls connection_or_send_authenticate_cell()
 command.c:1204 calls connection_or_send_netinfo()
   * These are in command_process_auth_challenge_cell(); the
     connection_or_send_* functions need to become channel_send_*.

 command.c:1275 calls connection_or_compute_authenticate_cell_body()
 command.c:1333 calls connection_or_set_circid_type()
 command.c:1336 calls connection_or_init_conn_from_address()
   * In command_process_authenticate_cell();
     connection_or_compute_authenticate_cell_body() should probably become
     channel_compute_authenticate_cell_body().

 config.c:1688 calls connection_or_update_token_buckets()
   * This is called while parsing config files if bandwidth limits change;
 does
     rate-limiting happen above or below the channel abstraction?

 connection.c:556 calls connection_or_remove_from_identity_map()
 connection.c:589 calls connection_or_remove_from_identity_map()
   * These are involved in freeing connections; they should check for the
     CONN_TYPE_OR case as now, but that will become part of a subclass of
 the
     channel_t mechanism, so they'll have to make a callback to a close
     handler through that, which is where these will happen instead.

 connection.c:621 calls connection_or_about_to_close()
   * Similar to above I think.

 connection.c:2678 calls connection_or_connect_failed()
   * Part of connection_handle_read_impl(); the CONN_TYPE_OR case will need
 to
     relay cells up to a channel_t callback now.

 connection.c:3027 calls connection_or_connect_failed()
   * Will have to pass the error on up through a callback here too.

 connection.c:3202 calls connection_or_connect_failed()
   * Error handling for connection_handle_write_impl(); similar to other
 error
     cases.
 connection.c:3828 calls connection_or_process_inbuf()
   * This can stay unchanged, but connection_or_process_inbuf() will have
 to
     pass the cells up to the right callback instead of whatever it does
 with
     them now.

 connection.c:3857 calls connection_or_flushed_some()
   * I think this can stay unchanged, but connection_or_flushed_some() will
     have to be checked.

 connection.c:3887 calls connection_or_finished_flushing()
 connection.c:3925 calls connection_or_finished_connecting()
 connection.c:3943 calls connection_or_reached_eof()
   * Similar to above.

 connection.c:4284 calls connection_or_clear_identity_map()
   * This will have to become a callback freeing all channels I think.

 connection_edge.c:3072 calls connection_or_digest_is_known_relay()
   * This is a check while opening a new exit connection; it should be
     per-channel I think.

 control.c:4702 calls connection_or_report_broken_states()
   * This should probably remain, since connection_or.c will still handle
 TLS stuff

 dirserv.c:3386 calls connection_or_connect()
 dirserv.c:3398 calls connection_or_connect()
   * These open connections for IPv4 and IPv6 respectively; should call a
     channel subclass instead.

 main.c:399 calls connection_or_remove_from_identity_map()
   * Connection cleanup in connection_unlink(); this gets used for lots of
     different connection types; do we need to split CONN_TYPE_OR out
     into something separate that handles channel_t?  What calls
     connection_unlink()?

 main.c:1054 calls connection_or_connect_failed()
 main.c:1095 calls connection_or_write_cell_to_buf()
   * run_connection_housekeeping(): closing bad connections and sending
     keepalives; these become channel_* functions.

 main.c:1484 calls connection_or_set_bad_connections()
   * run_scheduled_events(): also related to housekeeping stuff; probably
     should be tracking bad channels instead.

 networkstatus.c:1840 calls connection_or_update_token_buckets()
   * Handle updated info about rate limits in
     networkstatus_set_current_consensus(); where are we handling rate-
     limiting?

 relay.c:1236 calls connection_or_send_destroy()
   * In connection_edge_process_relay_cell() for RELAY_COMMAND_TRUNCATE;
 should
     become channel_send_destroy().

 relay.c:2286 calls connection_or_unlink_all_active_circs()
   * This is part of how we track which circuits on an or_connection_t have
     pending cells; it should become channel_unlink_all_active_circs().

 relay.c:2364 calls connection_or_flush_from_first_active_circuit()
   * Similar to preceding; should become
     channel_flush_from_first_active_circuit().

 relay.c:2543 calls connection_or_flush_from_first_active_circuit()
   * This is in append_cell_to_circuit_queue(), the orconn parameter needs
 to
     become a channel_t.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6465#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online