1. 20 Sep, 2019 4 commits
  2. 11 Sep, 2019 5 commits
  3. 26 Aug, 2019 2 commits
  4. 20 Aug, 2019 3 commits
  5. 16 Aug, 2019 2 commits
    • Philipp Winter's avatar
      Merge branch 'feature/31252' into develop · 8291822c
      Philipp Winter authored
    • Philipp Winter's avatar
      Support handing out decoy bridges to bots. · 7ceb25e3
      Philipp Winter authored
      This patch makes it possible to identify bots by inspecting HTTP request
      headers.  A CSV file, specified by BLACKLISTED_REQUEST_HEADERS_FILE,
      contains mappings from request header to a regular expression of the
      header's value, e.g.:
      Once a regular expression matches a client's request, we probably caught
      a bot.  This patch also makes it possible to respond to bot requests
      with a decoy bridge, e.g., to study what the owners of the bot intend to
      do with the bridge.  Decoy bridges are configured in the CSV file
      DECOY_BRIDGES_FILE.  The file maps a transport type and its IP address
      version to bridge lines, e.g.:
        vanillav4, FINGERPRINT
        obfs4v4,obfs4 FINGERPRINT ARGS
      This fixes <https://bugs.torproject.org/31252>
  6. 15 Aug, 2019 3 commits
  7. 13 Aug, 2019 1 commit
    • Philipp Winter's avatar
      Make BridgeDB export usage metrics. · 5cde59d9
      Philipp Winter authored
      Until now, we had no insight into how BridgeDB is being used.  We don't
      know the relative popularity of our distribution method; we don't know
      how many users BridgeDB sees; we don't know how many requests succeed or
      fail; and we don't know the relative popularity of transports that users
      This patch attempts to answer these questions by making BridgeDB export
      usage metrics.  At the end of each 24-hour measurement interval,
      BridgeDB will append usage metrics to the file METRICS_FILE, which is
      configured in bridgedb.conf.
      Our metrics keep track of the number of (un)successful requests per
      transport type per country code (or email provider) per distribution
      method.  This way, we get to learn that, say, over the last 24 hours
      there were 31-40 users in Iran who successfully requested an obfs4
      bridge over Moat.  The corresponding metrics line would look as follows:
        bridgedb-metric-count moat.obfs4.ir.success.none 40
      To make the metrics preserve user privacy, we don't collect
      user-identifying information and we introduce noise by rounding up
      metrics to our bin size which defaults to 10.
      This patch also extends the looping calls that BridgeDB spawns.  When
      BridgeDB first starts, it loads proxies from the files PROXY_LIST_FILES.
      It augments this list of proxies with Tor exit relays that we download
      every three hours.
  8. 12 Aug, 2019 5 commits
    • Philipp Winter's avatar
      Update comment. · 85a69d1b
      Philipp Winter authored
      Several variables that are referenced in the comment no longer exist.
    • Philipp Winter's avatar
      Fix broken download of Tor exit relays. · 0d5ed52e
      Philipp Winter authored
      The periodic download of Tor exit relays was broken for a number of
      reasons.  Here's what we're doing to fix this issue:
      1. We're moving the proxies variable outside of state.  The problem is
         that the state object is written to disk and reloaded every 30
         minutes (a cron job is triggering this reload by running
         ~/bridgedb-admin/reload-bridgedb).  The reload causes state.proxies
         to be at a different memory address than before the reload, which
         breaks the looping call that fetches new exit relays every three
         hours.  This looping call expects to write exit relays to the same
         memory address each time, but after BridgeDB's first reload, the
         memory address changed, so exit relays are no longer updated.
         There's no need to keep our proxies in BridgeDB's state.  We fetch
         them continuously anyway, and also right after BridgeDB starts.
      2. We're adding the method replaceExitRelays().  Once we have a new
         batch of exit relay addresses, this method allows us to completely
         overwrite the past batch.
      3. We're adding the argument "setStdout=False" to the call to
         startLogging() because otherwise we're missing the download script's
    • Philipp Winter's avatar
      Merge branch 'fix/26542' into develop · 081ff367
      Philipp Winter authored
    • Philipp Winter's avatar
      Update PIP_FLAGS to fix Travis CI update. · 8894939d
      Philipp Winter authored
    • Philipp Winter's avatar
      Add version filters for IPv6 vanilla bridges. · 594589ec
      Philipp Winter authored
      So far, BridgeDB's distribution of vanilla IPv6 bridges was broken.
      When a user would request one, BridgeDB would use the following two
      filters to select bridges:
      * byTransportNotBlockedIn(None,us,6)
      * byProbingResistance(vanilla,6)
      Neither filter (correctly) filtered for IPv6.  It is not enough to check
      bridge.address because it's the bridge's IPv4 address.  We need to check
      bridge.allVanillaAddresses because a bridge's IPv6 address is advertised
      in its "a" consensus line.
      Note that this patch only fixes IPv6 distribution for *vanilla* bridges.
      Pluggable transports bridges are currently unable to have dual-stack
      support for both IPv4 and IPv6.  See the following ticket for more
      details: <https://bugs.torproject.org/11211>
      This fixes <https://bugs.torproject.org/26542>.
  9. 24 Jul, 2019 1 commit
    • Philipp Winter's avatar
      Remove outdated documentation. · 21807e6e
      Philipp Winter authored
      BridgeDB no longer has a single handler for SIGUSR1.  It was removed in
      commit f4d55919.  As a result, if you now send a SIGUSR1 to BridgeDB, it
      reacts with the default action, which is termination.
  10. 26 Jun, 2019 1 commit
  11. 07 Jun, 2019 10 commits
  12. 06 Jun, 2019 1 commit
  13. 04 Jun, 2019 2 commits
    • Philipp Winter's avatar
      Merge branch 'bug28655' into develop · f279fa08
      Philipp Winter authored
    • Philipp Winter's avatar
      Don't burn active probing-resistant PTs. · efff3eb1
      Philipp Winter authored
      The GFW used to block bridges by IP address:port but a while ago, it
      started to block bridges by IP address instead.  This means that if a
      bridge runs obfs4 (which is active probing-resistant) and obfs3 (which
      is not active probing-resistant), and BridgeDB happens to hand out the
      bridge's obfs3 line, the GFW would manage to probe the bridge, and block
      the entire IP address, *including* obfs4.
      In this patch, we deal with the GFW's update by not handing out a
      bridge's probe-able protocols if it also runs an active
      probing-resistant protocol such as obfs4 or scramblesuit.
      The patch adds a new configuration option, PROBING_RESISTANT_TRANSPORTS,
      which must contain a list of active probing-resistant protocols.
      This fixes bug 28655: <https://bugs.torproject.org/28655>