[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4312 [Tor Relay]: Rate limit renegotiations
#4312: Rate limit renegotiations
-----------------------+----------------------------------------------------
Reporter: asn | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone:
Component: Tor Relay | Version:
Keywords: | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by asn):
Replying to [comment:7 nickm]:
> Looks ok.
>
> For the bufferevents case: The same callback-based approach works for
detecting excessive renegotiation, but we run into problems in knowing
what to do about it. We want to run some "kill this connection" callback
soon, but not immediately (because running that kind of thing from inside
the SSL callback from inside the bufferevent code is a recipe for Lots Of
The Wrong Kind Fun.) Probably, we could just use event_base_once code to
invoke a trampoline function to call the appropriate user-level callback
to call bufferevent_disable() and connection_mark_for_close() on the
connection. Does that make sense? I think it would work.
In the non-bufferevents case, the OpenSSL callbacks increment the
ClientHello-seen count, but they are not killing the connection. The
connection is killed after SSL_{read,write}() functions are done.
The problem with setting a "kill the connection" callback from within the
OpenSSL callbacks is that we only have access to the `tor_tls_t` in there.
I assume that calling a libevent event with the `tor_tls_t` attached and
doing a linear search over all the connections to find the `tor_tls_t`
bearer is super stupid, and we must find something better. If you have
something in mind, I indeed believe a callback-based approach is the
cleanest (we can also do that in the non-bufferevents case as well, and
stop catching excess renegotiations around the code.)
If a callback-based approach doesn't work, we might want to find a
bufferevents libevent cb function that gets called frequently (and by
'frequently' I mean that it should be called on new SSL traffic, and not
only on new SSL Application Data) and do a check there for excess
renegotiations.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4312#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs