|
|
== Why are we here?
|
|
|
We had a firefox patch and we don't anymore because it had bad side effects. #19910 and #24636 are the reasoning behind this.
|
|
|
|
|
|
== What is Optimistic Data?
|
|
|
Tor implemented Optimistic Data with Tor Spec proposals 174 and 181, for server and client-side respectively.
|
|
|
|
|
|
At a high level, this allows the application OP (onion proxy) to send application payload before the SOCKS handshake finishes. This effectively means the application data is already in-transit when the exit node successfully establishes a connection (or the data is already queued on the exit node and ready for transmission). There are a few ways this can be accomplished, but fundamentally this requires the applications begins sending data before the connection exists.
|
|
|
|
|
|
== What are the problems?
|
|
|
The main question is where this logic should be implemented.
|
|
|
1) If the application is Optimistic-Data-Aware, then it can start sending data after it tells Tor where it wants to connect and the application simply knows the first response it receives from the proxy is the last part of the SOCKS handshake.
|
|
|
2) If the logic is implemented in Tor, then the idea is tor lies to the application and immediately completes the SOCKS handshake with success and the application then (happily) starts sending its data.
|
|
|
|
|
|
In the case of (1), the application is responsible for correctly handling the error case when Tor's SOCKS response is a failure. This an easier application-level usability problem in comparison to option (2).
|
|
|
|
|
|
Option (2) is difficult because tor lies to the application and says the connection was successful despite it being in progress, and there is no guarantee the connection will succeed. How does tor signal the connection failed, after the fact? Out of band communication? In-band communication? SOCKS doesn't provide any mechanism for in-band control messages.
|
|
|
|
|
|
== What else is this like?
|
|
|
This is similar in intent to TCP Fast Open (rfc7413). Can we reuse any logic or learned experience from that? Especially in Firefox, is any of that implementation reusable?
|
|
|
|
|
|
== What can we do when tor lies and the connection fails?
|
|
|
Can we use a weird TCP flag (ex. URG) for signaling?
|
|
|
Is there another rarely used heuristic we can use?
|
|
|
Can we use an out-of-band/side-channel we can use (like the control port)?
|
|
|
Can we timeout the connection?
|
|
|
Can we simply hangup the socket and let the application do something smart?
|
|
|
|
|
|
== Is our life easier if the application knows how it should use optimistic data?
|
|
|
Yes. Application support is much better for usability. We should look deeper into the Firefox code and find why isn't working as expected. Specifically, there is a race condition between the SOCKS logic and the Application-Protocol logic. This race condition is reproducible (https://trac.torproject.org/projects/tor/ticket/24432#comment:19). We should.. (https://trac.torproject.org/projects/tor/ticket/21501#implement%20TFO%20aka%20TCP%20FAST%20OPEN%20to%20save%20RTT) .patch this.
|
|
|
|
|
|
== What are the risks with using this?
|
|
|
Some application data should not be replayable, the applications should use optimistic data with care. TCP Fast Open introduces similar risk, as documented in the RFC. |
|
|
\ No newline at end of file |