Opened 8 years ago

Closed 8 years ago

Last modified 6 years ago

#3375 closed defect (fixed)

NEWNYM does not abandon open rendezvous circuits

Reported by: rransom Owned by: rransom
Priority: High Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor has ignored a rendezvous circuit's timestamp_dirty field when choosing whether to attach a new stream to it since hidden services were first implemented in version 0.0.6, but this became a Bad Thing when SIGNAL NEWNYM was added in 0.1.1.15-rc (and implemented (uglily) by decreasing timestamp_dirty by a large amount, to make previously used circuits seem ‘too old’ for new streams).

Child Tickets

Change History (13)

comment:1 Changed 8 years ago by rransom

Status: newneeds_review

See abandon-rend-circs-on-newnym ( git://git.torproject.org/rransom/tor.git abandon-rend-circs-on-newnym ) for a fix.

comment:2 Changed 8 years ago by nickm

Looks like a plausible idea to me.

Do we want to be using the same MaxCircuitDirtiness for rendezvous circuits? It seems that this change would make us not only abandon circuits on newnym, but reintroduce to any hidden service that we want to stay connected to every MaxCircuitDirtiness seconds (current default 10 min, I think).

Is changing circuit_is_acceptable sufficient? That is, will the having this circuit present but non-usable cause new introduction attempts to be made correctly, or will new attempts to connect to the hidden service fail while it's around?

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

Replying to nickm:

Looks like a plausible idea to me.

Do we want to be using the same MaxCircuitDirtiness for rendezvous circuits? It seems that this change would make us not only abandon circuits on newnym, but reintroduce to any hidden service that we want to stay connected to every MaxCircuitDirtiness seconds (current default 10 min, I think).

A rendezvous circuit's timestamp_dirty is reset every time a stream is attached to it, so this change would only cause clients to reintroduce to a hidden service if they had a long-lived stream open and had not opened a new stream to the HS in the last 10 minutes. (If they don't have a long-lived stream open, Tor will currently close the circuit 10 minutes after the last time a stream was attached to it) I don't see a problem with using a new circuit in that case, and it may be beneficial (e.g. for reliability reasons).

Is changing circuit_is_acceptable sufficient? That is, will the having this circuit present but non-usable cause new introduction attempts to be made correctly, or will new attempts to connect to the hidden service fail while it's around?

When I tested this patch, a new attempt to connect to a hidden service after NEWNYM succeeded (in refetching the descriptor, reintroducing to the HS, and building and using a second rendezvous circuit).

comment:4 in reply to:  3 ; Changed 8 years ago by nickm

Replying to rransom:

Replying to nickm:

Looks like a plausible idea to me.

Do we want to be using the same MaxCircuitDirtiness for rendezvous circuits? It seems that this change would make us not only abandon circuits on newnym, but reintroduce to any hidden service that we want to stay connected to every MaxCircuitDirtiness seconds (current default 10 min, I think).

A rendezvous circuit's timestamp_dirty is reset every time a stream is attached to it,

Ow. This gives timestamp_dirty a different meaning for rendezvous circuits than for general circuits, where (unless I'm mistaken) only the first stream getting attached causes the circuit timestamp_dirty to get set.

so this change would only cause clients to reintroduce to a hidden service if they had a long-lived stream open and had not opened a new stream to the HS in the last 10 minutes. (If they don't have a long-lived stream open, Tor will currently close the circuit 10 minutes after the last time a stream was attached to it) I don't see a problem with using a new circuit in that case, and it may be beneficial (e.g. for reliability reasons).

I think that's _probably_ ok too, but it's definitely a behavior change, and as such I'm not too thrilled about having it in 0.2.1.x.

Roger, what do you think about this?


Is changing circuit_is_acceptable sufficient? That is, will the having this circuit present but non-usable cause new introduction attempts to be made correctly, or will new attempts to connect to the hidden service fail while it's around?

When I tested this patch, a new attempt to connect to a hidden service after NEWNYM succeeded (in refetching the descriptor, reintroducing to the HS, and building and using a second rendezvous circuit).

Great.

comment:5 in reply to:  4 Changed 8 years ago by rransom

Replying to nickm:

Replying to rransom:

Replying to nickm:

Looks like a plausible idea to me.

Do we want to be using the same MaxCircuitDirtiness for rendezvous circuits? It seems that this change would make us not only abandon circuits on newnym, but reintroduce to any hidden service that we want to stay connected to every MaxCircuitDirtiness seconds (current default 10 min, I think).

A rendezvous circuit's timestamp_dirty is reset every time a stream is attached to it,

Ow. This gives timestamp_dirty a different meaning for rendezvous circuits than for general circuits, where (unless I'm mistaken) only the first stream getting attached causes the circuit timestamp_dirty to get set.

Yes. See also the changes/ entry for one of my patches for #1297 -- starting in 0.0.6, one piece of Tor expected timestamp_dirty to have even more meanings for HS-related circuits, but it didn't actually have that meaning.

comment:6 in reply to:  4 Changed 8 years ago by arma

Priority: criticalmajor

Replying to nickm:

Replying to rransom:

A rendezvous circuit's timestamp_dirty is reset every time a stream is attached to it,

Ow. This gives timestamp_dirty a different meaning for rendezvous circuits than for general circuits, where (unless I'm mistaken) only the first stream getting attached causes the circuit timestamp_dirty to get set.

Correct. The idea was that the rendezvous process is expensive, so as long as you're still interacting with the hidden service, we should make it over the same circuit.

Because we don't rotate circuits every 10 minutes for hidden services, a) interactions are faster and smoother, and b) interactions are more linkable.

so this change would only cause clients to reintroduce to a hidden service if they had a long-lived stream open and had not opened a new stream to the HS in the last 10 minutes. (If they don't have a long-lived stream open, Tor will currently close the circuit 10 minutes after the last time a stream was attached to it) I don't see a problem with using a new circuit in that case, and it may be beneficial (e.g. for reliability reasons).

I think that's _probably_ ok too, but it's definitely a behavior change, and as such I'm not too thrilled about having it in 0.2.1.x.

It is definitely a behavior change. But I pondered the patch for a while and I think it should be ok to apply, either to 0.2.1 directly or to 0.2.2 with plans to backport 'sometime'.

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

Replying to rransom:

Replying to nickm:

Is changing circuit_is_acceptable sufficient? That is, will the having this circuit present but non-usable cause new introduction attempts to be made correctly, or will new attempts to connect to the hidden service fail while it's around?

When I tested this patch, a new attempt to connect to a hidden service after NEWNYM succeeded (in refetching the descriptor, reintroducing to the HS, and building and using a second rendezvous circuit).

Did you test it with a stream open during the newnym? I worry that your test did a newnym, causing the circuit to become dirty, causing it to be closed, and then of course your new connection worked as expected.

comment:8 in reply to:  7 ; Changed 8 years ago by rransom

Replying to arma:

Replying to rransom:

Replying to nickm:

Is changing circuit_is_acceptable sufficient? That is, will the having this circuit present but non-usable cause new introduction attempts to be made correctly, or will new attempts to connect to the hidden service fail while it's around?

When I tested this patch, a new attempt to connect to a hidden service after NEWNYM succeeded (in refetching the descriptor, reintroducing to the HS, and building and using a second rendezvous circuit).

Did you test it with a stream open during the newnym?

Yes. I opened one stream to an IRC hidden service, sent SIGNAL NEWNYM to the control port, and then opened another stream to the same hidden service; I read the control-port event logs produced by SETEVENTS SIGNAL STREAM CIRC carefully, and then verified that I had two circuits open to the same hidden service using GETINFO circuit-status.

I also performed the same test without this patch, and that version of Tor sent the stream opened after NEWNYM over the previously existing rendezvous circuit (and did not build a second rendezvous circuit).

comment:9 in reply to:  8 Changed 8 years ago by arma

Replying to rransom:

Replying to arma:

Did you test it with a stream open during the newnym?

Yes.

Great.

I think this is ready to merge. I'll let Nick decide if he wants to merge into 0.2.1 or 0.2.2.

comment:10 Changed 8 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merging into 0.2.1. It'll see some testing in 0.2.2 before another 0.2.1 release comes out.

comment:11 Changed 7 years ago by nickm

Keywords: tor-client added

comment:12 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:13 Changed 6 years ago by nickm

Milestone: Tor: 0.2.1.x-final

Milestone Tor: 0.2.1.x-final deleted

Note: See TracTickets for help on using tickets.