#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs