Opened 8 years ago

Closed 5 years ago

#3890 closed enhancement (implemented)

Applications should start using optimistic data

Reported by: nickm Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: SponsorZ, needs-triage
Cc: iang@…, rransom, arma, t55wang@…, ln5 Actual Points:
Parent ID: #5456 Points:
Reviewer: Sponsor:

Description

If we've got any applications that speak a protocol where latency matters, and where connections typically start out with the client sending data, then we should look into making them support optimistic data. (This means that the client sends data before hearing about whether the socks connection is successful.)

I'm calling this "bundles", but it should mostly focus on application-specific subtickets.

Child Tickets

TicketTypeStatusOwnerSummary
#8184taskclosedmikeperryVerify path bias code plays well with optimistic data

Change History (17)

comment:1 Changed 8 years ago by iang

Cc: iang@… added

Shouldn't 3711 be listed as a child?

comment:2 Changed 8 years ago by nickm

Type: defectenhancement

comment:3 Changed 8 years ago by nickm

Whee. Turning it into an enhancement makes it list its children. Trac-eriffic!

comment:4 Changed 8 years ago by arma

Added #3875 as another child

comment:5 Changed 7 years ago by mikeperry

Cc: rransom arma added
Parent ID: #5456
Priority: normalmajor

While staring at my circuit window fretting about #5456, I realized that the Tor client behavior of retrying stream stages prior to RELAY_CONNECTED allows an active exit node attacker to embed an arbitrarily long timing signature transparently during stream setup. Because this phase is still transparent to the user, the circuit still can be closed at this step if the timing signature is not detected on a colluding malicious guard, allowing for resource amplification. It's not as much amplification as tagging via cipher malleability, because you don't get to do it at both ends, but it's still amplification.

But if we deploy optimistic data, we remove the amplification property because if the stream does not succeed in that first round trip, the app will actually experience failure instead of the Tor client transparently retrying until a signature can be added.

So it turns out this performance feature is actually a security improvement as well.

comment:6 Changed 7 years ago by mikeperry

Blech. Unfortunately, the most likely way we'll end up supporting DNSSEC will allow this timing signature to be re-introduced if the user wants end to end authentication for DNS resolutions..

We'll need to make sure there are no ways the DNS server can tell the client "try again soon, please".. I guess I should be noting this on any tickets/proposals about DNSSEC, but those have not materialized yet.

comment:7 Changed 7 years ago by arma

Milestone: Sponsor Z: November 1, 2013

comment:8 Changed 7 years ago by t55wang

Cc: t55wang@… added

comment:9 Changed 7 years ago by karsten

Keywords: SponsorZ added
Milestone: Sponsor Z: November 1, 2013

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

comment:10 Changed 7 years ago by ln5

Cc: ln5 added

comment:11 Changed 7 years ago by nickm

Karen's requested an eli5 explanation here.

So, we already went and implemented a feature in Tor that allows applications to begin sending data before they get a confirmation from the exit node that the connection has completed.

That's useful, because for protocols where the client talks first, it lets the clients avoid a "round trip" in the connection setup time. Previously, there would be 2 round trips across the network for a basic HTTP request: one to connect and wait for the exit to say "connected", and then another to send the HTTP request and wait for an HTTP response. But with this features, the connect and the HTTP request leave the client for the exit at the same time, and the "connected" and the HTTP respons can come back at the same time.

But there's a problem: Applications don't actually support this yet. Even though the application is allowed to start sending the HTTP request immediately, most of them still wait for Tor to say "you're connected!" So this performance enhancement isn't getting used.

If we come up with a workable solution here, it would let us improve applications (like say firefox) so that they start each connection faster, with less latency than they currently have.

comment:12 Changed 7 years ago by iang

Ah, I just realized what "eli5" meant. :-p How's this?

As we know, Tor is somewhat slow. This slowness is made worse by the following problem:

The way Tor works now, when your Tor browser wants to connect to a website (say BBC), it sends a message over the Tor network to an exit node, telling it to connect to the BBC (this is slow because sending messages over the Tor network is slow). The exit node connects to the BBC web server, and reports back to the Tor browser (over the Tor network) that it has succeeded. (This is slow because sending messages over the Tor network is slow). The Tor browser then sends a message to the BBC web server (over the Tor network) asking for a particular web page. (This is slow because sending messages over the Tor network is slow).

The key idea behind this improvement is to bundle the "which web page to get" message along with the "connect to the BBC web server" message. So with this improvement, it would look like:

When your Tor browser wants to connect to a website (say BBC), it sends a message over the Tor network to an exit node, telling it to connect to the BBC *and fetch a particular web page* (this is slow because sending messages over the Tor network is slow). The exit node connects to the BBC web server, and when it succeeds, the *exit node* then sends a message to the BBC web server (*not* over the Tor network) asking for the particular web page. This saves a round trip over the Tor network, and should make the Tor network much more responsive for web browsing.

comment:13 Changed 7 years ago by iang

[I still haven't parsed what "ln5" stands for, though. :-p ]

comment:14 in reply to:  13 Changed 7 years ago by nickm_mobile

Replying to iang:

[I still haven't parsed what "ln5" stands for, though. :-p ]

"ln5" is Linus Nordberg.

comment:15 Changed 5 years ago by erinn

Keywords: needs-triage added

comment:16 Changed 5 years ago by erinn

Component: Tor bundles/installationTor Browser
Owner: changed from erinn to tbb-team

Can we close this?

comment:17 Changed 5 years ago by arma

Resolution: implemented
Status: newclosed

I think you can jettison #3711 from the children and close it yes.

In fact, done.

Note: See TracTickets for help on using tickets.