Tor 0.3.2.8-rc is released, with important updates for relays

by nickm | December 21, 2017

Tor 0.3.2.8-rc fixes a pair of bugs in the KIST and KISTLite schedulers that had led servers under heavy load to overload their outgoing connections. All relay operators running earlier 0.3.2.x versions should upgrade. This version also includes a mitigation for over-full DESTROY queues leading to out-of-memory conditions: if it works, we will soon backport it to earlier release series.

This is the second release candidate in the 0.3.2 series. If we find no new bugs or regression here, then the first stable 0.3.2 release will be nearly identical to this.

You can download the source from the usual place on the website. Binary packages should be available soon. There probably won't be a Tor Browser release for this one; this issues fixed here are mainly (but not exclusively) relevant to relays.
 

Changes in version 0.3.2.8-rc - 2017-12-21

  • Major bugfixes (KIST, scheduler):
    • The KIST scheduler did not correctly account for data already enqueued in each connection's send socket buffer, particularly in cases when the TCP/IP congestion window was reduced between scheduler calls. This situation lead to excessive per-connection buffering in the kernel, and a potential memory DoS. Fixes bug 24665; bugfix on 0.3.2.1-alpha.
  • Minor features (geoip):
    • Update geoip and geoip6 to the December 6 2017 Maxmind GeoLite2 Country database.

 

  • Minor bugfixes (hidden service v3):
    • Bump hsdir_spread_store parameter from 3 to 4 in order to increase the probability of reaching a service for a client missing microdescriptors. Fixes bug 24425; bugfix on 0.3.2.1-alpha.
  • Minor bugfixes (memory usage):
    • When queuing DESTROY cells on a channel, only queue the circuit-id and reason fields: not the entire 514-byte cell. This fix should help mitigate any bugs or attacks that fill up these queues, and free more RAM for other uses. Fixes bug 24666; bugfix on 0.2.5.1-alpha.
  • Minor bugfixes (scheduler, KIST):
    • Use a sane write limit for KISTLite when writing onto a connection buffer instead of using INT_MAX and shoving as much as it can. Because the OOM handler cleans up circuit queues, we are better off at keeping them in that queue instead of the connection's buffer. Fixes bug 24671; bugfix on 0.3.2.1-alpha.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

December 27, 2017

Permalink

What is the status of option __AllDirActionsPrivate in current tor versions? It is not documented in man torrc, but I can see some mentioning in control-spec.txt, in bug reports (with relation to crash, probably already fixed), and in old (more than 10 years) Roger's recommendations. Is it safe to use?

I need my tor parsing programs to use full nodes' descriptors. Recommended way to get it is to enable options

FetchDirInfoEarly 1
FetchDirInfoExtraEarly 1
FetchUselessDescriptors 1

However, it results in like 10 extra connections of my tor client to some random tor nodes. I guess this can be used to easily profile me among other tor clients. So, I think about possibility to start my tor client with standard config and then, after start, do SETCONF through ControlPort (with these 3 options and with the option __AllDirActionsPrivate). I suppose that from outside it will look like more typical tor client connection than without the option __AllDirActionsPrivate. What's Tor Project's opinion on this solution?

Peter Ott (not verified) said:

January 02, 2018

Permalink

Hello,
any idea (link) from where to download the 0.3.2.8-rc for Windows. TOR gives a warning that the 0.3.2-rc is outdated.
I'm running only a relay so the 'Expert bundle' is needed not the 'Browser'. Thanks in advance.

Amin amin (not verified) said:

January 04, 2018

Permalink

Nice

Red (not verified) said:

January 11, 2018

Permalink

A question what are you guys opinion of googles search lock add on to chrome. I am just starting to learn what you guys already know. Recently retired and have found i like to learn about computing. Not that I know much but google is pushing me toward search lock. I am not sure I like being pushed.It all started with me disabling there info gathering from my google account.Is search lock a benefit? whats in it for google? Whats the best road for an inexperienced but growing user. Thank you Red

jose (not verified) said:

January 23, 2018

Permalink

1/23/2018 22:39:06 PM.300 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/23/2018 22:39:06 PM.300 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/23/2018 22:39:06 PM.300 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/23/2018 22:39:06 PM.300 [NOTICE] Opening Socks listener on 127.0.0.1:9150
1/23/2018 22:39:06 PM.300 [NOTICE] Renaming old configuration file to "C:\Users\XONE\Desktop\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.3"
1/23/2018 22:39:07 PM.300 [NOTICE] Bootstrapped 5%: Connecting to directory server
1/23/2018 22:39:07 PM.500 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server

1/23/2018 22:39:15 PM.400 [WARN] 10 connections have failed:
1/23/2018 22:39:15 PM.400 [WARN] 10 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
1/23/2018 22:39:15 PM.400 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
1/23/2018 22:39:15 PM.400 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/23/2018 22:39:15 PM.400 [NOTICE] Closing old Socks listener on 127.0.0.1:9150
1/23/2018 22:39:16 PM.400 [NOTICE] Delaying directory fetches: DisableNetwork is set.