Opened 4 years ago

Last modified 8 months ago

#12537 new enhancement

Perhaps BridgeDB should supply decoys

Reported by: andrea Owned by: isis
Priority: Low Milestone:
Component: Obfuscation/BridgeDB Version:
Severity: Normal Keywords: bridgedb-email, sql-injection, XKEYSCORE, forthelulz
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


The opposition would like to enumerate bridges and does stuff like this:

requires grammar version 5
 * Identify clients accessing Tor bridge information.
fingerprint('anonymizer/tor/bridge/tls') =
ssl_x509_subject('') or

 * Database Tor bridge information extracted from confirmation emails.
fingerprint('anonymizer/tor/bridge/email') =
  and email_body('' : c++
  extractors: {{
    bridges[] = /bridge\s([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}):?([0-9]{2,4}?[^0-9])/;
  init: {{
  main: {{
    static const std::string SCHEMA_OLD = "tor_bridges";
    static const std::string SCHEMA_NEW = "tor_routers";
    static const std::string FLAGS = "Bridge";
    if (bridges) {
      for (size_t i=0; i < bridges.size(); ++i) {
        std::string address = bridges[i][0] + ":" + bridges[i][1];
        DB[SCHEMA_OLD]["tor_bridge"] = address;
        DB[SCHEMA_NEW]["tor_ip"] = bridges[i][0];
        DB[SCHEMA_NEW]["tor_port_or"] = bridges[i][1];
        DB[SCHEMA_NEW]["tor_flags"] = FLAGS;
    return true;


If some of the bridge IPs they managed to scrape in this fashion were randomly generated decoys, they would have to do more work to explicitly test them.

Child Tickets

Change History (6)

comment:1 Changed 4 years ago by andrea

Component: - Select a componentBridgeDB
Owner: set to isis

comment:2 Changed 4 years ago by bastik

As I see it, the user requesting the bridges can't tell the decoys apart from the actual bridges or the extracting adversary would be able do to the same.

(I was expecting China to do this extraction, but not the USA. China might still do it, too.)

What's the clients (probably only relevant for TB) current behavior for entering decoys (as well as working bridges)? Like, will there be a warning to the user that 3 out of 6 bridges didn't respond?

Some of the randomly generated addresses (most in IPv4 will, in IPv6 not so much) will be actually in use. Is it nice to put the machines (and operators/owners) behind those IP addresses in a database?

Considering the adversary is adapting its filter by only keeping entires in the database that get repeatedly extracted, since the real addresses aren't changing all that often, but random addresses are possibly random all the time, I think that BridgeDB should generated decoys at random and send the same decoys to multiple users. It shouldn't refresh the decoys too often.

End of ticket related content.

(The NSA and whoever else might watch me for posting to the Tor mailing lists, or running bridges, which got my name attached to them, or just for connecting to the network or simply visiting this website, but that's what I put myself into.)

(I don't want to open another ticket, because I think it's not worth it, but it is related. Since Tor users are expected to check the signature of their Tor (or TB) copy with PGP, bridge requesting users could provide their public-key in the message body or as attachment and BridgeDB sends an encrypted email to them. It's not worth it in my eyes, because PGP has to be deployed on the server and fed with user-provided input, in normal case the key, which has to be stored at least temporary, what's not making me that sad since the adversary would be able to extract the key from the email in the first place. The major downside is that if it is optional, the adversary will get the bridges from those that do not make use of this feature. And if it is forced, this makes it much more difficult for people to get bridges. EDIT: Found #12536)

Last edited 4 years ago by bastik (previous) (diff)

comment:3 Changed 4 years ago by yawning

The VPN Gate folks do something along these lines, and apparently it also frustrated the GFW people who were scraping the distribution page (and ended up blocking several fairly large websites). I have heard from people that bridgedb did this in the past but does not anymore, but I do not recall the reasons for this.

See section 4.2 of

comment:4 Changed 4 years ago by isis

(Cross-posted from the tor-talk mailing list post):

Hash: SHA512

Eugen Leitl transcribed 5.8K bytes:

Errata Security

Advanced persistent cybersecurity

Friday, July 04, 2014

Jamming XKeyScore

Back in the day there was talk about "jamming echelon" by adding keywords to email that the echelon system was supposedly looking for. We can do the same thing for XKeyScore: jam the system with more information than it can handle. (I enumerate the bugs I find in the code as "xks-00xx").

For example, when sending emails, just send from the address "bridges at" and in the email body include:
bridge =
bridge =
bridge =

Continue this for megabytes worth of bridges (xks-0001), and it'll totally mess up XKeyScore. It has no defense against getting flooded with information like this, as far as I can see.

Hi. I maintain and develop BridgeDB.

For what it's worth, the released XKS rules would not have worked against
BridgeDB for over a year now. I have no knowledge of what regexes are
currently in use in XKS deployments, nor if the apparent typos are errors in
the original documents, or rather typos in one of the various levels of
transcriptions which may have occurred in the editing process. If these typos
were at some point in the original rules running on XKS systems, then *no*
bridges would have been harvested due to various faults. None.

Ergo, as Jacob has pointed out to me, the regexes which are released should be
assumed to be several years out of date, and also shouldn't be assumed to be
representative of the entire ruleset of any deployed XKS system.

I am willing to implement tricks against specific problems with them, mostly
for the lulz, because fuck the NSA. But it should be assumed that the actual
regexes have perhaps been updated, and that highly specific tricks are not
likely to land.

The ticket for this, by the way, was created by Andrea this afternoon, it's

Note that the regex only cares about 1 to 3 digit numbers, that means the following will be accepted by the system (xks-0002):

bridge = 75.748.86.91:80

The port number matches on 2 to 4 digits ([0-9]{2,4}). Therefore, bridges with port numbers below 10 and above 9999 will be safe. I don't know if this code reflect a limitation in Tor, or but assuming high/low ports are possible, this can be used to evade detection (xks-0011).

Strangely, when the port number is parsed, it'll capture the first non-digit character after the port number (xks-0012). This is normally whitespace, but we could generate an email with 256 entries, trying every possible character. A character like < or ' might cause various problems in rendering on an HTML page or generating SQL queries.

Interesting. I'm glad someone else is paying that close of attention to these
regexes. I'd totally take a patch which implements the BridgeDB equivalent of
little Bobby'); DROP TABLE Students.

Granted, as I said above, it likely won't land. But for the lulz. :)

Robert Graham

  • -- ♥Ⓐ isis agora lovecruft

GPG: 4096R/A3ADB67A2CDB8B35
Current Keys:


Last edited 4 years ago by isis (previous) (diff)

comment:5 Changed 3 years ago by isis

Cc: isis added
Keywords: bridgedb-email sql-injection XKEYSCORE forthelulz added
Priority: normalminor
Type: defectenhancement

comment:6 Changed 8 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.