Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3535 closed enhancement (implemented)

Relax IsolateDestAddr rules to handle hostname/ip distinction

Reported by: nickm Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: #1865 Points:
Reviewer: Sponsor:

Description

The current prop171 branch takes a simplistic view of isolating streams by destination address, and treats any two addresses as equal only if they equal in a case-insensitive string comparison. But if address A has resolved to IP B, then perhaps we don't want to isolate future requests for A and B onto separate circuits.

There may also be other circumstances like this, such as where hostname A and hostname B are both known to resolve to IP C.

Child Tickets

Change History (7)

comment:1 Changed 8 years ago by nickm

Status: newaccepted

For what it's worth, we probably shouldn't implement a system where A and B can share a circuit under IsolateDestAddr when they both share a foo.com suffix. That way lies ad-network.site-you-wanted.com.

comment:2 in reply to:  description ; Changed 8 years ago by arma

Replying to nickm:

The current prop171 branch takes a simplistic view of isolating streams by destination address, and treats any two addresses as equal only if they equal in a case-insensitive string comparison. But if address A has resolved to IP B, then perhaps we don't want to isolate future requests for A and B onto separate circuits.

If the user actually asks for destinations A and B and they are different, we should respect the isolation requests. I think it's only where the user asks for destination A and then asks for destination A again later, and in between the Tor client has cached the resolve and does a remap for the second request, that we should realize they're the same.

I could imagine recognizing that they're the same by crawling the mapaddresses, or by just remembering the "originally requested address" somewhere in the stream and consulting that when considering isolation.

There may also be other circumstances like this, such as where hostname A and hostname B are both known to resolve to IP C.

Open research question whether that's a good idea. So I think it should default to "no, keep those separate" until somebody gives us a better intuition.

comment:3 in reply to:  2 Changed 8 years ago by arma

Replying to arma:

There may also be other circumstances like this, such as where hostname A and hostname B are both known to resolve to IP C.

Open research question whether that's a good idea. So I think it should default to "no, keep those separate" until somebody gives us a better intuition.

On more thought, I think it may be a bad idea. If DNS resolves were authenticated in some bulletproof way, it might be better. But they're not, and I can imagine an exit relay that hands back an IP address of a stream it wants you to mingle this new stream with. Best to leave Tor's internal remapping out of the picture and just use the addresses that the applications hand to Tor.

comment:4 Changed 8 years ago by nickm

Status: acceptedneeds_review

Okay, this approach is now implemented in prop171. Closer and closer!

comment:5 Changed 8 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

comment:6 Changed 7 years ago by nickm

Keywords: tor-client added

comment:7 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.