Set up default bridge at Karlstad University

added TorBrowserTeam201909R component::applications/tor browser owner::phw points::0.5 priority::medium resolution::fixed severity::normal status::closed tbb-bridges type::project labels

Hi, Tobias Pulls here.

This is vacation times in Sweden, things get back to normal towards the middle of August. The next step on my side is to get the local research engineers that run our network fully on board with replacing our relay with a default bridge. In particular, we need to look at where in our network to put the bridge make sure high load or any blacklisting of IPs associated with the bridge have minimal impact on the rest of the network. Will update as soon as I know more, ball in my corner.

Replying to pulls:

fully on board with replacing our relay with a default bridge

Replacing? Why choose? :)

Replying to arma:

Replying to pulls:

fully on board with replacing our relay with a default bridge

Replacing? Why choose? :)

Bandwidth is precious! :) Maybe the relay will find its way back later if there's room.

I got an OK to use 1 gbit of our link. Will upgrade the hardware of the box (lacked AESNI) this week. To use the full link, should the box run more than one instance of tor? Something else to keep in mind? Appreciate any help here.

Replying to pulls:

I got an OK to use 1 gbit of our link. Will upgrade the hardware of the box (lacked AESNI) this week. To use the full link, should the box run more than one instance of tor? Something else to keep in mind? Appreciate any help here.

Great news! Two tor instances sound like a good plan. Several other default bridge operators are doing this: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges

Another thing that just came to my mind: Please set BridgeDistribution to none in your torrc, so your bridge isn't distributed by BridgeDB. As explained in #13727 (moved), this prevents users from using both your (publicly known) default bridge and a private bridge at the same time, which may help a censor discover the private bridge.

I've been using

EntryStatistics 1
ExtraInfoStatistics 1

for gathering more metrics and

HeartbeatPeriod 1 hour

for my own sake.

I've been using various ServerTransportOptions, most notably iat-mode to obfs4, by request from dcf and others.

Some of the obfs bridges I run have AssumeReachable 1 together with a local IP filter blocking traffic to the ORPort, to not expose the ORPort.

Thanks for the advice! We ended up having to order hardware, should be up next week.

Replying to phw:

Replying to pulls:

I got an OK to use 1 gbit of our link. Will upgrade the hardware of the box (lacked AESNI) this week. To use the full link, should the box run more than one instance of tor? Something else to keep in mind? Appreciate any help here.

Great news! Two tor instances sound like a good plan. Several other default bridge operators are doing this: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges

Depending on the exact hardware, you may need 3-4 instances to fully saturate the link. Our experience is that each tor instance can do 250 - 400 Mbps on fast hardware.

But start with two, and see how you go :-)

Progress made, three bridges up and running with the following torrc:

SocksPort auto
RunAsDaemon 1
ExtORPort auto
ExitPolicy reject *:*

# memory
MaxMemInQueues 2 GB

# more useful statistics
EntryStatistics 1
ExtraInfoStatistics 1
HeartbeatPeriod 1 hour

# obfs4 and parameters
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportOptions obfs4 iatMode=0

# announce bridges
BridgeRelay 1
BridgeDistribution none

# These ports must be externally reachable.  Avoid port 9001.
ServerTransportListenAddr obfs4 0.0.0.0:27015
ORPort 27018

# identity
Nickname KauBridgePale
ContactInfo abuse-tor@lists.kau.se

Bridgelines here:

Bridge obfs4 193.11.166.194:27015 2D82C2E354D531A68469ADF7F878FA6060C6BACA cert=4TLQPJrTSaDffMK7Nbao6LC7G9OW/NHkUwIdjLSS3KYf0Nv4/nQiiI8dY2TcsQx01NniOg iat-mode=0
Bridge obfs4 193.11.166.194:27020 86AC7B8D430DAC4117E9F42C9EAED18133863AAF cert=0LDeJH4JzMDtkJJrFphJCiPqKx7loozKN7VNfuukMGfHO0Z8OGdzHVkhVAOfo1mUdv9cMg iat-mode=0
Bridge obfs4 193.11.166.194:27025 1AE2C08904527FEA90C4C4F8C1083EA59FBC6FAF cert=ItvYZzW5tn6v3G4UnQa6Qz04Npro6e81AP70YujmK/KXwDFPTs3aHXcHp4n8Vt6w/bv8cA iat-mode=0

Anything you want me to change in the torrc or we good to go?

Adding some more memory to the box, going to require brief downtime tomorrow or early next week.

The memory we bought ended up not working in the box (...), ordering new ones for a second attempt.

Hi, memory finally installed. As far as I'm concerned, good to go.

I'm changing the ticket category to Tor Browser, to get the following two patches merged:

My project/31164 branch has a patch for tor-browser-build.
My project/31164 branch has a patch for tor-android-service.

I added the three new bridges to our sysmon configuration and to our default bridge wiki page.

Trac:
Status: assigned to needs_review
Component: Circumvention to Applications/Tor Browser

Trac:
Keywords: N/A deleted, TorBrowserTeam201909R added

Thanks! Merged to tor-browser-build's master (commit e5922c8fc4c518112f2b32f57319306770071c3e) and to tor-android-service's (commit 8d307a63a95a31d3578715ca407066062f9d7f5e; commit f13ad8814b2024c2fe02c8a163534d99c545cf86 on tor-browser-build's master picks that change up).

I guess if we make another 8.5 point release we could think about backporting the patches.

Trac:
Status: needs_review to closed
Keywords: N/A deleted, tbb-backport added
Resolution: N/A to fixed

We had both of our uplinks die at the same time twice over the weekend, taking the entire department's equipment including the bridges offline. This isn't suppose to happen, sorry. IT staff investigating and monitoring, so far nothing abnormal detected on either side of the uplinks.

No esr60-based builds anymore and thus no backport.

Trac:
Keywords: tbb-backport deleted, N/A added

closed

changed time estimate to 4h

Set up default bridge at Karlstad University

Child items 0

Activity