Opened 6 years ago

Closed 5 years ago

#9174 closed defect (worksforme)

Bridgedb obfs detection not relieable

Reported by: hsn Owned by: isis
Priority: High Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: bridgedb-assignments, bridgedb-parsers
Cc: karsten, isis, sysrqb Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

my bridge runs obfs3 on port 9993 which is accessible from outside but I am not listed as obfs3 bridge:

"pool_assignment":"https ip=4 ring=2 flag=stable port=443"

Child Tickets

Change History (25)

comment:1 Changed 6 years ago by cypherpunks

Priority: normalmajor

I have same problem. Currently running obfs3 bridge is waste of resources because bridgedb is unreliable. There is zero support for announcing transport ports to bridge db and be able to read them back. You can not announce different ports from your listening ports, so there is no way to run them on port 80 or 53.

This should be high priority for project. Sadly all obfs transport things are low priority.

comment:2 Changed 6 years ago by hsn

Bridgedb dump is here:

https://onionoo.torproject.org/details?type=bridge

there are 62 bridges (both running and not running) with any obfs transport. This is way low because there is about 350 cloud bridges and cloud bridge image supports both transports.

comment:3 in reply to:  description Changed 6 years ago by sysrqb

Replying to hsn:

my bridge runs obfs3 on port 9993 which is accessible from outside but I am not listed as obfs3 bridge:

"pool_assignment":"https ip=4 ring=2 flag=stable port=443"

What does it say if you query your bridge on https://atlas.torproject.org ?

comment:4 in reply to:  2 Changed 6 years ago by sysrqb

Replying to hsn:

Bridgedb dump is here:

https://onionoo.torproject.org/details?type=bridge

there are 62 bridges (both running and not running) with any obfs transport. This is way low because there is about 350 cloud bridges and cloud bridge image supports both transports.

sysrqb@localhost $ curl https://onionoo.torproject.org/details?type=bridge > ~/all_bridges
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1785k    0 1785k    0     0  1400k      0 --:--:--  0:00:01 --:--:-- 1401k
sysrqb@localhost $ grep obfs3 all_bridges | wc -l
168
sysrqb@localhost $ grep obfs2 all_bridges | wc -l
225


I don't know why you saw fewer bridges when you queried it.

comment:5 Changed 6 years ago by hsn

atlas did not found bridge by name. i do not know to search syntax for hash

"hashed_fingerprint":"434DBA6A34CF2F3FDDB6064A3C018477AB542AEE",

comment:6 Changed 6 years ago by hsn

you have bug in grep command, it should be: grep -c obfs3 otherwise you count also lines around result

my results:

grep -c obfs3 details\?type=bridge

94

grep -c obfs2 details\?type=bridge

141

grep -c obfs3,obfs2 details\?type=bridge

94

comment:7 Changed 6 years ago by sysrqb

Replying to hsn:

atlas did not found bridge by name. i do not know to search syntax for hash

"hashed_fingerprint":"434DBA6A34CF2F3FDDB6064A3C018477AB542AEE",

You can't look up a bridge using its hashed fingerprint. Can you try searching on atlas using the fingerprint in the 'fingerprint' file in your tor data directory?

comment:8 Changed 6 years ago by hsn

no results found in atlas.

comment:9 in reply to:  8 Changed 6 years ago by sysrqb

Status: newneeds_information

Replying to hsn:

no results found in atlas.


Ok, how can I reproduce this? You're running Tor 0.2.4.14-alpha on FreeBSD? Is there anything else that is special about your setup/configuration?

comment:10 Changed 6 years ago by hsn

i have forwarded ORPort, it announces and listents on diffent port and assumereachable turned on because it did not worked.

comment:11 Changed 6 years ago by hsn

it would be best if listed bridge can run with disabled ORport.

comment:12 Changed 6 years ago by asn

hi. i dug into the bridgedb extra info descriptors. the bridge named DarkSideOfAvalon01 runs obfsproxy with obfs3 that listens on port 9993. Am I correct?

I'm not sure why the transport does not appear in onionoo.

comment:13 in reply to:  1 Changed 6 years ago by asn

I have same problem. Currently running obfs3 bridge is waste of resources because bridgedb is unreliable. There is zero support for announcing transport ports to bridge db and be able to read them back. You can not announce different ports from your listening ports, so there is no way to run them on port 80 or 53.

This should be high priority for project. Sadly all obfs transport things are low priority.

That's #7875.

it would be best if listed bridge can run with disabled ORport.

That's #7349.

comment:14 in reply to:  12 Changed 6 years ago by hsn

Replying to asn:

hi. i dug into the bridgedb extra info descriptors. the bridge named DarkSideOfAvalon01 runs obfsproxy with obfs3 that listens on port 9993. Am I correct?

yes

comment:15 Changed 6 years ago by asn

Cc: karsten added

CCing Karsten. Maybe he knows why the transport does not appear in onionoo.

comment:16 Changed 6 years ago by karsten

Here's how you search for this bridge using Onionoo:

https://onionoo.torproject.org/details?search=DarkSideOfAvalon01

So, the pool_assignments field is solely based on what BridgeDB reports for this bridge in its pool assignments. Here are the entries for this bridge from today:

2013-07-03-00-00-22:434dba6a34cf2f3fddb6064a3c018477ab542aee https ip=4 ring=2 flag=stable port=443
2013-07-03-00-30-21:434dba6a34cf2f3fddb6064a3c018477ab542aee https ip=4 ring=2 flag=stable port=443
2013-07-03-01-00-19:434dba6a34cf2f3fddb6064a3c018477ab542aee https ip=4 ring=2 flag=stable port=443
2013-07-03-01-30-21:434dba6a34cf2f3fddb6064a3c018477ab542aee https ip=4 ring=2 flag=stable port=443
2013-07-03-02-00-30:434dba6a34cf2f3fddb6064a3c018477ab542aee https ip=4 ring=2 flag=stable port=443
2013-07-03-02-30-21:434dba6a34cf2f3fddb6064a3c018477ab542aee https ip=4 ring=2 flag=stable port=443
2013-07-03-03-00-30:434dba6a34cf2f3fddb6064a3c018477ab542aee https ip=4 ring=2 flag=stable port=443
2013-07-03-03-30-29:434dba6a34cf2f3fddb6064a3c018477ab542aee https ip=4 ring=2 flag=stable port=443

Note that the bridge wasn't contained in pool assignments after 03:30 UTC, which is quite a few hours in the past. Apparently, the bridge isn't running right now.

Here's how a pool assignments line would look like for an obfs2 and obfs3 bridge:

06cca6d1c73e99a17d571d5d0854ffa09414eef2 email ip=4 flag=stable port=443 transport=obfs3,obfs2

So, I'd say look at BridgeDB logs to see if something's wrong there.

comment:17 Changed 6 years ago by hsn

so problem is in bridgedb not assigning that bridge to obfs3 pool even if bridge reports that.

comment:18 Changed 6 years ago by cypherpunks

Hi,i started obfs3 bridge yesterday and have same problem. obfs3 is not detected by bridgedb.

This is annoying because there is difficult to tell if my setup works correctly.

comment:19 Changed 6 years ago by hsn

Problem still persists, bridge only occasionally gets listed as obfs3.

#9264 might be root cause of this

comment:20 in reply to:  19 Changed 6 years ago by sysrqb

Replying to hsn:

Problem still persists, bridge only occasionally gets listed as obfs3.

#9264 might be root cause of this

I think #9264 is indeed part of the problem. When we determine what causes the duplicate entries then a bridge's transport will sometimes be reported consistently. However, unless I'm mistaken, there is a second, underlying, problem that is occurring. Your bridge, and possibly others, is not publishing its transport consistently. There are multiple periods of time where your bridge's descriptor did not mention it supports the obfs3 PT.

Has your bridge constantly run the obfs3 PT for the past 3 weeks? Or were there periods of time when you did not run the obfs3?

If the former then we have more to investigate.

comment:21 Changed 6 years ago by hsn

it always runs obfs3, but sometimes for few hours is not online due to wifi connection problem.

comment:22 Changed 6 years ago by cypherpunks

I have the same problem - no obfs in the pool_assignment field.
ServerTransportPlugin obfs2,obfs3 exec /usr/local/bin/obfsproxy managed

comment:23 Changed 6 years ago by sysrqb

Keywords: important added

comment:24 Changed 5 years ago by isis

Cc: isis sysrqb added
Keywords: bridgedb-assignments bridgedb-parsers added; obfs important removed
Owner: set to isis
Status: needs_informationassigned

I have not heard of an occurrence of this bug in a while. It's also unclear to me whether this is a bug in BridgeDB's dumping of assignments files, or a bug in onionoo not parsing those assignments files correctly, or a bug in little-t tor where bridges aren't properly reporting their transports, or some user error in searching onionoo/atlas.

I'm closing this bug, feel free to reopen (and/or reassign to another component) if this problem persists.

comment:25 Changed 5 years ago by isis

Resolution: worksforme
Status: assignedclosed
Note: See TracTickets for help on using tickets.