Opened 5 months ago

Closed 4 months ago

#31252 closed enhancement (implemented)

Equip BridgeDB with anti-bot mechanism

Reported by: phw Owned by: phw
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Normal Keywords:
Cc: phw Actual Points: 2
Parent ID: Points: 4
Reviewer: cohosh Sponsor:

Description

BridgeDB sees many bot requests. The ones I've seen cycle over exit relays to fetch several bridge types (obfs2 (!), obfs3, obfs4, scramblesuit, and vanilla) from BridgeDB's HTTPS interface. Interestingly, they get most captchas right.

We don't know who's operating these bots or what they are doing with their bridges but we should make BridgeDB more resistant to these attacks. Let's add a mechanism that allows us to configure request headers that BridgeDB should ignore, e.g., requests whose user agent contains curl.

Ideally, instead of BridgeDB responding "bots aren't allowed to get bridges," we could serve an empty response, or a decoy bridge whose only purpose is to find out what the bot operators are doing with it.

Child Tickets

Change History (4)

comment:1 Changed 4 months ago by phw

Reviewer: cohosh
Status: assignedneeds_review

I have an implementation in my feature/31252 branch. The patch uses two new configuration files, which is a bit of a nuisance but we shouldn't be storing blacklisted request headers or decoy bridges in bridgedb.conf because the file is public. Instead, we want to keep these configuration options hidden from our adversaries.

comment:2 Changed 4 months ago by cohosh

Status: needs_reviewmerge_ready

This looks good to me. Do we need to add this to the specification?

I'm interested in how the decisions on what headers to blacklist will be made. Since the files are meant to not be public, is there some process we go through to add new things to the blacklist or ensure that we're not introducing too many false positives here?

The idea of giving out a decoy bridge is very nice. It would be interesting to see where/when this bridge gets blocked.

comment:3 in reply to:  2 ; Changed 4 months ago by phw

Replying to cohosh:

This looks good to me. Do we need to add this to the specification?


We probably should. The spec seems in dire need of an overhaul. I filed #31426 for this.

I'm interested in how the decisions on what headers to blacklist will be made. Since the files are meant to not be public, is there some process we go through to add new things to the blacklist or ensure that we're not introducing too many false positives here?


Hmm, good question. I suggest that we bring up the overall approach in our weekly meeting (i.e., that we start using regular expressions to look for bot requests) and coordinate the specific regular expressions among ourselves, in private. Does this sound reasonable? Do we have a better idea?

The idea of giving out a decoy bridge is very nice. It would be interesting to see where/when this bridge gets blocked.


Yes, I intend to set up a private bridge for this purpose.

comment:4 in reply to:  3 Changed 4 months ago by phw

Actual Points: 2
Resolution: implemented
Status: merge_readyclosed

Merged and deployed.

Note: See TracTickets for help on using tickets.