[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:  needs_review      
 Priority:  major      |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor Relay  |        Version:  Tor: unspecified  
 Keywords:             |         Parent:                    
   Points:             |   Actualpoints:                    
-----------------------+----------------------------------------------------

Comment(by andrea):

 Replying to [comment:36 nickm]:
 > I think so.  By the specification, padding cells are part of the Tor
 protocol.

 Yeah, but so are the auth/version/netinfo cells.  To some extent, anything
 you could possibly do with this [1] other than just wedge it between
 circuit_t and or_connection_t as an abstraction layer is about
 experimenting with different protocols on the wire.  The combination of
 channel_t and channel_tls_t/or_connection_t implements the protocol in the
 specification, and if it doesn't it's a bug - but the whole point of this
 is to allow experimentation with alternatives, so the choice of how much
 to genericize and handle above the channel layer and how much to handle
 below is relevant too and orthogonal to whether the
 channel_t/channel_tls_t/or_connection_t stack here implements the same
 protocol the old or_connection_t did.

 I opted for as much flexibility about different lower layers as possible,
 possibly at the expense of making it more work to implement new ones, so
 the interface
 channel_t exposes is pretty simple: it just passes the cells concerned
 with circuits and relaying things over them, namely CELL_CREATE,
 CELL_CREATE_FAST, CELL_CREATED, CELL_CREATED_FAST, CELL_RELAY,
 CELL_RELAY_EARLY or CELL_DESTROY, as you can see from
 command_process_cell() in command.c.  The things above channel_t assume if
 a channel gets to CHANNEL_STATE_OPEN it's authenticated the remote end and
 so we can trust that we're really speaking to the OR the channel's
 identity_digest says we are, but it's up to the
 or_connection_t/channel_tls_t lower layer to handle the authentication,
 and any alternate lower layer that gets implemented would have to define
 its own protocol and handle authentication too.

 Anyway, the case of the padding cell types seemed analogous, that I had to
 make a decision about whether to treat them as generic enough that they
 would be a feature of any reasonable protocol that could deliver cells to
 circuits and should be handled above channel_t, or if they were specific
 to the particular protocol we use now and should go below it.  Since they
 were treated as no-ops on reception except for incrementing a counter, it
 seemed like the latter.

 [1] Except maybe some stuff about experimenting with alternate
 implementations of the specification protocol like the thing ioerror
 suggested about privilege separation.

 > > See channel_tls_handle_cell() in channeltls.c; we set handshaking =
 > > (TO_CONN(conn)->state != OR_CONN_STATE_OPEN), which was the same test
 > > used in the old command_process_cell(), and then if we see anything
 other
 > > than NETINFO or VERSIONS with that true we kill the connection.
 >
 > ok.  There also used to be a DOS issue where you could send a bunch of
 data to bloat a
 > server's buffers and get it ignored while the server was waiting for a
 v2 tls handshake.
 > But it's unlikely we reintroduced that and kept the v3 handshake working
 too.

 No, I don't think it is.  The channel code doesn't even start receiving
 any cells until after the handshake is done and it goes to
 CHANNEL_STATE_OPEN.  Everything before the handshake is pretty much the
 same logic it was before, except the parts that used to be in command.c
 are in channeltls.c now and some of the variables that used to be in the
 or_connection_t struct are now in channel_t.

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