Tor 0.2.6.8 is released

by nickm | May 21, 2015

Hi, I've just put out a new stable Tor release. It is not a high-urgency item for most clients and relays, but directory authorities should upgrade. Right now, the source is available on the website, and packages should become available one their maintainers build them.

Tor 0.2.6.8 fixes a bit of dodgy code in parsing INTRODUCE2 cells, and fixes an authority-side bug in assigning the HSDir flag. All directory authorities should upgrade.

Changes in version 0.2.6.8 - 2015-05-21

  • Major bugfixes (hidden services, backport from 0.2.7.1-alpha):
    • Revert commit that made directory authorities assign the HSDir flag to relay without a DirPort; this was bad because such relays can't handle BEGIN_DIR cells. Fixes bug 15850; bugfix on tor-0.2.6.3-alpha.
  • Minor bugfixes (hidden service, backport from 0.2.7.1-alpha):
    • Fix an out-of-bounds read when parsing invalid INTRODUCE2 cells on a client authorized hidden service. Fixes bug 15823; bugfix on 0.2.1.6-alpha.
  • Minor features (geoip):
    • Update geoip to the April 8 2015 Maxmind GeoLite2 Country database.
    • Update geoip6 to the April 8 2015 Maxmind GeoLite2 Country database.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

May 21, 2015

Permalink

A new big bug has been found in SSL.

There’s a new problem with SSL called “Logjam”, here’s what you need to know
http://thenextweb.com/insider/2015/05/20/theres-a-new-problem-with-ssl-…

Test for 'The Logjam Attack'
https://weakdh.org/

I tried all ciphers with the current final and alpha Torbrowsers on https://weakdh.org/

Here are the results:

Good News! Your browser is safe against the Logjam attack.
security.ssl3.ecdhe_rsa_aes_256_sha
security.ssl3.ecdhe_ecdsa_aes_256_sha
security.ssl3.dhe_rsa_camellia_256_sha
security.ssl3.dhe_dss_aes_256_sha
security.ssl3.dhe_rsa_des_ede3_sha
security.ssl3.ecdhe_rsa_des_ede3_sha
security.ssl3.rsa_aes_256_sha
security.ssl3.rsa_camellia_256_sha
security.ssl3.rsa_des_ede3_sha
security.ssl3.dhe_dss_aes_128_sha
security.ssl3.dhe_dss_camellia_128_sha
security.ssl3.dhe_dss_camellia_256_sha
security.ssl3.dhe_rsa_camellia_128_sha
security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256
security.ssl3.ecdhe_ecdsa_aes_128_sha
security.ssl3.ecdhe_rsa_aes_128_gcm_sha256
security.ssl3.ecdhe_rsa_aes_128_sha
security.ssl3.rsa_aes_128_sha
security.ssl3.rsa_camellia_128_sha
security.ssl3.rsa_fips_des_ede3_sha
security.ssl3.rsa_seed_sha

Warning! Your web browser is vulnerable to Logjam
and can be tricked into using weak encryption. You should update your browser.
security.ssl3.dhe_rsa_aes_256_sha
security.ssl3.dhe_rsa_aes_128_sha

RC4 ciphers i always disable since Jacob Appelbaum told us:
"RC4 is broken in real time by the #NSA - stop using it."

Now i wonder if Tor is affected by this bug. But still, if memory serves Tor uses Elliptic Curve Diffie-Hellman.

I disabled RC4 in Firefox/Torbrowser. Type about:config, then RC4, switch them all to FALSE. That is all.

I am quite sure that Torbrowser looks about the same under Linux and Windows.

"I disabled RC4 in Firefox/Torbrowser. Type about:config, then RC4, switch them all to FALSE. That is all."

Why then are all of mine on Tor set to True?

Voce devia aprender a postar em ingles, na proxima talvez nem receba resposta...
Em principio isso seria um bug temporario, se fizer nova identidade ja devera conseguir ver o circuito.
Outra hipotese era que o security slider esteja muito alto, e ai mexe com o circuit.
Se isso continuar abra um ticket em ingles com o problema e a descriçao (os que usa, paginas de exempplo etc)

Obrigado! eu escrevi em português porque eu não sei escrever corretamente em inglês!

Era realmente apenas um bug temporário, reiniciei o navegador e tudo voltou ao normal.

Anonymous (not verified) said:

May 22, 2015

Permalink

I am looking for Tor developers comment on how Logjam affects TOR NETWORK. It is clear that Tor Browser can be easily fixed, but what about connections between TOR NODES and HIDDEN SERVICES?

As near as I can tell, it should not affect current Tor software very much,
for a few reasons:

  • All currently supported Tor versions, when built with OpenSSL 1.0 or
    later, prefer 256-bit elliptic-curve Diffie Hellman for their TLS
    connections, not the 1024-bit Diffie Hellman over Z_p as discussed in
    this paper.
  • We have never enabled "Export" crypto server-side or client-side.
  • All currently supported Tor versions perform their circuit handshakes
    using the Curve25519-based "ntor" protocol, not the old "TAP" protocol
    which used 1024-bit DH.
  • Actually, I think even the TAP protocol might be safe, since it sends an encrypted g^x, so even if you can take the discrete log of g^y, you don't even have g^x to use it with unless you can also break RSA1024.
  • The TLS encryption in Tor is, for the most part, redundant with the layer
    of forward secrecy in the circuit handshakes, so that if either one is
    secure, Tor traffic should not be decryptable.

Recommendations:

  • If you've ignored all our requests to upgrade to a recent Tor version
    (0.2.6 stable would be best), please do so soon. Anything older than
    0.2.4 is NOT supported.
  • If you're running OpenSSL 0.9.8 or earlier, you should consider upgrading
    to 1.0.0 or later.
  • Make sure to apply vendor patches for your non-Tor software as they
    become available.

It's been more than 20 days now. I think someone forgot they were a maintainer... Anyone tried poking them to see if we can see this release? I could just build from source but then *I* become accountable for keeping things up-to-date.

Anonymous (not verified) said:

May 22, 2015

Permalink

An article about colluding Autonomous Systems, safer circuit-building, timing atttack countermeasures, and better load balancing:

http://arxiv.org/pdf/1505.05173.pdf

The researchers also looked at whether decreasing the number of guards makes users safer (it doesn't always).

Anonymous (not verified) said:

May 24, 2015

Permalink

Important: Their is a security vulnerability with this website's encryption.
Go to Qualys SSL Labs and click on Test your site and type in www.torproject.org. And then you will find out the vulnerability with this website's encryption.
This problem needs to be fixed as soon as possible. Otherwise somebody could hack into this website. Nobody want's that to happen.
If the Tor project keep's their website secure, then Tor itself will also be secure.

Anonymous (not verified) said:

May 24, 2015

Permalink

I'm sure that Tor project will fix this vulnerability with their website's encryption.
I hope so, as everyone who uses Tor should.

Anonymous (not verified) said:

May 25, 2015

Permalink

TorBrowser ignores "StrictNodes" completely when accessing hidden services! This is a huge security risk!

Please add option to force 3 nodes to be from different country because China -> China -> China is BAD!

Anonymous (not verified) said:

May 25, 2015

Permalink

Anything being done about this? This is the message I get.

The Logjam Attack

https://weakdh.org/

Warning! Your web browser is vulnerable to Logjam and can be tricked into using weak encryption. You should update your browser.

Anonymous (not verified) said:

May 26, 2015

Permalink

I was looking through other tweaks that apply to Firefox to see how it's set in Tor. I came across webgl which they say is a major security risk. Tor has it set to False by default when it should be set to True. And if Jacob Appelbaum said to stop using RC4, why is Tor's default set to True?

Anonymous (not verified) said:

May 28, 2015

Permalink

>TorBrowser ignores "StrictNodes" completely when accessing hidden services! This is a huge security risk!

>Please add option to force 3 nodes to be from different country because China -> China -> China is BAD!

StrictNodes isn't for internal circuits it's for exiting circuits. So it doesn't apply to accessing hidden services. I made the same mistake.

If you want to force building paths which avoid problem countries you can look into the NodeFamily option for your torrc file. If you put a country code in brackets like {cc1}, {cc2} you'll avoid using circuits with more than one.

For example: NodeFamily {cn}, {kp} would use no more than one node in china and north korea. Note that you need at least two {cc} to form a family.

Careful! StrictNodes is only for ExcludeNodes. It isn't for ExitNodes. I assume whoever made the earlier comment is confused and is using it wrong (and without any actual details, it's hard to tell either way). It looks like you're confused and are using it wrong too -- "StrictNodes isn't for internal circuits it's for exiting circuits" is not true.

That said, your use of NodeFamily looks reasonable. I hadn't thought of doing it that way. Go you. :)

Anonymous (not verified) said:

May 29, 2015

Permalink

A question for Tor developers: Why is StartPage not the default search engine in Tor browser 4.0.5 as it used to be?

Anonymous (not verified) said:

June 02, 2015

Permalink

"On May 23rd, 2015 Anonymous said:

still waiting for the debian/ubuntu packages :)"

me too, still can't find them on deb.torproject.org :/

Anonymous (not verified) said:

June 12, 2015

Permalink

Hello. Please tell me how to disable HTML canvas extraction pop-up notification. I find it very annoying. Also, please tell me how to open a new tab. This new release only allows for new windows!
Thanks,
Vice