[tor-bugs] #33644 [Circumvention/Snowflake]: Upgrade tor on Snowflake bridge for TROVE-2020-002
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Mar 24 02:10:21 UTC 2020
#33644: Upgrade tor on Snowflake bridge for TROVE-2020-002
-------------------------------------+------------------------
Reporter: dcf | Owner: dcf
Type: task | Status: closed
Priority: High | Milestone:
Component: Circumvention/Snowflake | Version:
Severity: Normal | Resolution: fixed
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------+------------------------
Changes (by dcf):
* status: assigned => closed
* resolution: => fixed
Comment:
It's done. The snowflake bridge is now running tor 0.3.5.10 and Debian
10.3.
I mainly followed the instructions at
https://www.debian.org/releases/buster/amd64/release-notes/ch-
upgrading.en.html. Our old /etc/apt/sources.list was
{{{
deb http://ftp.nl.debian.org/debian stretch main
deb http://security.debian.org/ stretch/updates main
}}}
I changed it to
{{{
deb http://ftp.nl.debian.org/debian buster main
deb http://ftp.nl.debian.org/debian-security buster/updates main
deb http://ftp.nl.debian.org/debian buster-updates main
}}}
I wasn't sure about the `buster/updates` and `buster-updates` lines
because they were not mentioned in the upgrade guide. I found them used in
the example sources.list at
https://wiki.debian.org/SourcesList#Example_sources.list.
I had to preserve local changes in /etc/ferm/ferm.conf and /etc/tor/torrc,
while merging in the updates.
After the installation there were these obsolete packages:
{{{
# aptitude search '~o'
Warning: Invalid locale (please review locale settings, this might lead to
problems later):
locale::facet::_S_create_c_locale name not valid
i deb.torproject.org-keyring -
GnuPG archive key of the deb.torproject.org repository
i gcc-4.8-base -
GCC, the GNU Compiler Collection (base package)
i gcc-4.9-base -
GCC, the GNU Compiler Collection (base package)
i A gcc-6-base -
GCC, the GNU Compiler Collection (base package)
i libapt-inst1.5 -
deb package format runtime library
i libapt-pkg4.12 -
package management runtime library
i libboost-iostreams1.55.0 -
Boost.Iostreams Library
i libcryptsetup4 -
disk encryption support - shared library
i libdns-export100 -
Exported DNS Shared Library
i libgdbm3 -
GNU dbm database routines (runtime version)
i libgnutls-deb0-28 -
GNU TLS library - main runtime library
i libhogweed2 -
low level cryptographic library (public-key cryptos)
i libicu52 -
International Components for Unicode
i libirs-export91 -
Exported IRS Shared Library
i libisc-export95 -
Exported ISC Shared Library
i libisccfg-export90 -
Exported ISC CFG Shared Library
i libjson-c2 -
JSON manipulation library - shared library
i liblogging-stdlog0 -
easy to use and lightweight logging library
i liblognorm1 -
Log normalizing library
i libnettle4 -
low level cryptographic library (symmetric and one-way cryptos)
i libprocps3 -
library for accessing process information from /proc
i libpsl0 -
Library for Public Suffix List (shared libraries)
i libreadline6 -
GNU readline and history libraries, run-time libraries
i libssl1.0.0 -
Secure Sockets Layer toolkit - shared libraries
i libxtables10 -
netfilter xtables library
i linux-image-3.16.0-4-amd64 -
Linux 3.16 for 64-bit PCs
i A perl-modules-5.24 -
Core Perl modules
}}}
I removed them with `aptitude purge '~o'`
I rebooted the system at 2020-03-24 01:36:54 and was able to SSH back in
at 2020-03-24 01:37:56. I checked that the firewall rules were still in
place, that tor was running and managing snowflake-server, and the three
proxy-gos were running and able to write logs.
I decided not to install the linux-image-amd64 metapackage as
[https://www.debian.org/releases/buster/amd64/release-notes/ch-
upgrading.en.html#newkernel this section of the upgrade guide]
recommended, because after rebooting I found that the kernel version was
5.4.20, while the version of linux-image-amd64 was 4.19.0. The 5.4.20
kernel may be an eclips.is kernel, but I'm not sure.
I was running a Turbo Tunnel Snowflake browser at the time, and after
rebooting the server the browser was not responding and its tor log said
{{{
3/24/20, 01:16:47.922 [NOTICE] Delaying directory fetches: No running
bridges
3/24/20, 01:30:23.680 [NOTICE] Application request when we haven't
received a consensus with exits. Optimistically trying known bridges
again.
3/24/20, 01:32:24.735 [NOTICE] Delaying directory fetches: No running
bridges
3/24/20, 01:33:38.850 [NOTICE] Application request when we haven't
received a consensus with exits. Optimistically trying known bridges
again.
3/24/20, 01:42:40.275 [NOTICE] Delaying directory fetches: No running
bridges
}}}
This makes sense, as a server restart isn't something Turbo Tunnel can
recover from--the end-to-end session is broken and snowflake-client has to
wait until tor makes another SOCKS request. I used the trick of switching
to obfs4 for one second and then switching back to snowflake, and it
started working again right away.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33644#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list