[tor-bugs] #6465 [Tor Relay]: Build abstraction layer around TLS
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Wed Sep 19 19:31:33 UTC 2012
#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
More information about the tor-bugs
mailing list