Opened 8 years ago

Closed 8 years ago

#5229 closed defect (fixed)

ooni-probe/bridget should make sure that random port numbers are not already taken

Reported by: karsten Owned by: hellais
Priority: Medium Milestone:
Component: Archived/Ooni Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: #5028 Points:
Reviewer: Sponsor:

Description

The bridget plugin of ooni-probe generates random Control and SOCKS ports between 49152 and 65535 and a random Tor data directory containing an int between 0 and 424242424242. The ports are problematic here, because Tor won't start if a port is already in use. We already ran into this case. The plugin should make sure that a port number wasn't picked before, or it will conclude that a bridge is offline when it may be reachable. The directory name generation could also be improved, e.g., by using an internal counter.

Child Tickets

Change History (7)

comment:1 Changed 8 years ago by runa

Milestone: Sponsor E: March 15, 2012

This is related to #5028 (Tor bridge scanning), so setting Sponsor E as the milestone.

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

Replying to karsten:

The bridget plugin of ooni-probe generates random Control and SOCKS ports between 49152 and 65535 and a random Tor data directory containing an int between 0 and 424242424242. The ports are problematic here, because Tor won't start if a port is already in use. We already ran into this case. The plugin should make sure that a port number wasn't picked before, or it will conclude that a bridge is offline when it may be reachable.

The plugin should use SocksPort auto and ControlPort auto.

The directory name generation could also be improved, e.g., by using an internal counter.

Or generate a random string containing at least 128 bits of entropy. (Use a real random number generator for this.)

I do hope something cleans up old data directories.

comment:3 in reply to:  1 Changed 8 years ago by karsten

Milestone: Sponsor E: March 15, 2012

Replying to runa:

This is related to #5028 (Tor bridge scanning), so setting Sponsor E as the milestone.

#5028 is sponsor F, and that one is already assigned to the sponsor milestone. At least for sponsor F, we're not assigning child tickets to the sponsor milestone, just the project tickets. Unassigning.

comment:4 in reply to:  2 ; Changed 8 years ago by karsten

Replying to rransom:

The plugin should use SocksPort auto and ControlPort auto.

That might work, too. We probably don't want to run Tor versions before 0.2.2.26-beta, do we?

The directory name generation could also be improved, e.g., by using an internal counter.

Or generate a random string containing at least 128 bits of entropy. (Use a real random number generator for this.)

In theory, there's no need to introduce a random component here. A single thread creates these directories.

I do hope something cleans up old data directories.

Yes.

comment:5 Changed 8 years ago by karsten

Parent ID: #5028

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

Replying to karsten:

Replying to rransom:

The plugin should use SocksPort auto and ControlPort auto.

That might work, too. We probably don't want to run Tor versions before 0.2.2.26-beta, do we?

Hopefully not. 0.2.1.x is no longer supported, and we have had security bugfixes on the 0.2.2.x branch since it became stable.

The directory name generation could also be improved, e.g., by using an internal counter.

Or generate a random string containing at least 128 bits of entropy. (Use a real random number generator for this.)

In theory, there's no need to introduce a random component here. A single thread creates these directories.

In practice, datadir_basename = base64.b32encode(foozerkit.randombytes(16)).lower() is simpler, and thus easier and less likely to break, than the non-random approaches you had in mind. (See my safecookie-python tor-utils branch for the randombytes function if you don't already have one.)

comment:7 Changed 8 years ago by hellais

Resolution: fixed
Status: newclosed

This is fixed in commit 4c683479e44c44def4ecb1ddf1326509a0450caa. Can you try out to see if the problem in #5209 still happens?

Note: See TracTickets for help on using tickets.