Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#23958 closed defect (not a bug)

Onionoo not fetching the bridge descriptor correctly?

Reported by: dgoulet Owned by: metrics-team
Priority: Very High Milestone:
Component: Metrics/Onionoo Version:
Severity: Normal Keywords:
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

All Tor browser bridges are flagged offline by Atlas where Onionoo is seeing a "last published timestamp" for all of them at:

bridges_published:"2017-10-23 16:41:35",

I suspect an Onionoo issue else could be a bridge auth problem?

Child Tickets

Change History (13)

comment:1 Changed 2 years ago by karsten

Hmm, which bridges are wrongly flagged offline? Can you paste hashed fingerprints here?

comment:2 Changed 2 years ago by dgoulet

One example, this is my bridge and I can confirm it is still working:

CDF2E852BF539B82BD10E27E9115A31734E378C2

comment:3 Changed 2 years ago by karsten

Hmm, that bridge is listed without the Running flag in the current status:

r Lisbeth 2cgFyVXLEk0YjA1E8nHpvlfeIQk dV+DnxzqEqZp2szNgJoirs4yI+A 2017-10-23 17:39:35 10.244.31.79 59950 0
s Fast Stable V2Dir Valid
w Bandwidth=7175
p reject 1-65535

Is there any reason why the bridge authority would take away the Running flag?

Can you also check the other bridges that you think should have the Running flag in that status?

If you can't resolve this easily, I can try to take another look tomorrow. Not sure what to look for yet, though.

comment:4 Changed 2 years ago by dgoulet

Well almost all default Tor browser bridge I looked up today gave me a downtime from Onionoo. I can't get Atlas to query them now (backend error :S).

88CD36D45A35271963EF82E511C8827A24730913
011F2599C0E9B27EE74B353155E244813763C3E5
C73ADBAC8ADFDBF0FC0F3F4E8091C0107D093716
CDF2E852BF539B82BD10E27E9115A31734E378C2
A09D536DD1752D542E1FBB3C9CE4449D51298239
FE7840FE1E21FE0A0639ED176EDA00A3ECA1E34D
91A6354697E6B02A386312F68D82CF86824D3606
8FB9F4319E89E5C6223052AA525A192AFBC85D55
C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4
0BAC39417268B96B9F514E7F63FA6FBA1A788955
A832D176ECD5C7C6B58825AE22FC4C90FA249637
BBB28DF0F201E706BE564EFE690FE9577DD8386D
D9A82D2F9C2F65A18407B1D2B764F130847F8B5D
8DFCD8FB3285E855F5A55EDDA35696C743ABFC4E
7B126FAB960E5AC6A629C729434FF84FB5074EC2
00DC6C4FA49A65BD1472993CF6730D54F11E0DBB
FC259A04A328A07FED1413E9FC6526530D9FD87A

comment:5 Changed 2 years ago by dgoulet

More example with names: zipfelmuetze or griinchux which are

011F2599C0E9B27EE74B353155E244813763C3E5
91A6354697E6B02A386312F68D82CF86824D3606

Running flag has been stripped from them also...

comment:6 Changed 2 years ago by isis

Cc: isis added

I don't see anything obviously wrong with the BridgeAuth; it appears to be doing reachability testing. Perhaps there's something wrong further down the line, like maybe CollecTor isn't successfully getting bridge descriptor tarballs from the BridgeDB machine?

comment:7 Changed 2 years ago by isis

BridgeDB doesn't have the Running flag on the networkstatus-bridges entry for dgoulet's bridge:

bridgedb@polyanthum:/srv/bridges.torproject.org$ grep -R -A30 Lisbeth from-bifroest
from-bifroest/networkstatus-bridges:r Lisbeth zfLoUr9Tm4K9EOJ+kRWjFzTjeMI 43sBjkmml79Lm1k1LV7ZPx0XASM 2017-10-23 20:41:35 192.95.36.142 9001 0                
from-bifroest/networkstatus-bridges-s Fast Stable V2Dir Valid

So it's actually missing the Running flag entirely, and this is probably not Onionoo/Collector doing anything weird.

comment:8 Changed 2 years ago by isis

netcatting to dgoulet's bridge's ORPort from the BridgeAuth seems to be working fine…

comment:9 Changed 2 years ago by dcf

I'm pretty sure that this is the case for all the Tor Browser default bridges, and it's because we ask the bridge operators to block their ORPort from outside access. This is to prevent reachability tests from succeeding, and so keep the default bridges out of BridgeDB.

For the default bridges, having them in BridgeDB does nothing but make them more discoverable to a censor: in addition to being scraped from the source code, they can also be harvested through BridgeDB, or be detected on the wire when some user connects to them using vanilla Tor (easily fingerprintable) instead of obfs4.

Blocking the ORPort is a workaround we have been applying for the default bridges for a long time, until #18329 is fixed. Also #7349 is related: most bridges can't hide their ORPort because they will be kept out of BridgeDB and be useless, but default bridges don't need BridgeDB so they can enhance their security by hiding their ORPort.

comment:10 in reply to:  9 ; Changed 2 years ago by dcf

Replying to dcf:

I'm pretty sure that this is the case for all the Tor Browser default bridges, and it's because we ask the bridge operators to block their ORPort from outside access. This is to prevent reachability tests from succeeding, and so keep the default bridges out of BridgeDB.

See for instance this thread about the addition of zipfelmuetze and griinchux:

https://lists.torproject.org/pipermail/tor-project/2017-August/001369.html
In addition, it is best if you use a firewall to block the bridge's regular ORPort (while leaving the obfs4 port unblocked). Blocking the bridge's ORPort is a hack to prevent the bridge from being included in BridgeDB, which eliminates a couple of ways a censor might discover and block the bridge: 1) by enumerating BridgeDB, and 2) by fingerprinting plain-Tor connections to the bridge's IP address (made by users who discovered the plain-Tor port through BridgeDB).

comment:11 in reply to:  9 Changed 2 years ago by karsten

Replying to dcf:

Blocking the ORPort is a workaround we have been applying for the default bridges for a long time, until #18329 is fixed. Also #7349 is related: most bridges can't hide their ORPort because they will be kept out of BridgeDB and be useless, but default bridges don't need BridgeDB so they can enhance their security by hiding their ORPort.

Thanks, dcf! So there's no bug in Onionoo, right? Can we close this issue, or is there a reason to keep it open?

comment:12 Changed 2 years ago by dgoulet

Resolution: not a bug
Status: newclosed

Yes big thanks dcf! That makes complete sense now. :)

comment:13 in reply to:  10 Changed 2 years ago by isis

Replying to dcf:

Replying to dcf:

I'm pretty sure that this is the case for all the Tor Browser default bridges, and it's because we ask the bridge operators to block their ORPort from outside access. This is to prevent reachability tests from succeeding, and so keep the default bridges out of BridgeDB.

See for instance this thread about the addition of zipfelmuetze and griinchux:

https://lists.torproject.org/pipermail/tor-project/2017-August/001369.html
In addition, it is best if you use a firewall to block the bridge's regular ORPort (while leaving the obfs4 port unblocked). Blocking the bridge's ORPort is a hack to prevent the bridge from being included in BridgeDB, which eliminates a couple of ways a censor might discover and block the bridge: 1) by enumerating BridgeDB, and 2) by fingerprinting plain-Tor connections to the bridge's IP address (made by users who discovered the plain-Tor port through BridgeDB).


FWIW, this hack is no longer needed (for that purpose), since #18329, #21177, and #23957 have been merged (and backported where necessary). Moving forward, TB default bridges (once on a new enough tor version) may put BridgeDistribution none in their torrc. It's still a good idea for TB default bridges to firewall off their ORPort, however, to protect against discoverability, since really only the PTs are useful.

Last edited 2 years ago by isis (previous) (diff)
Note: See TracTickets for help on using tickets.