Tor Browser 7.0a2 is released

Tor Browser 7.0a2 is now available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox.

This alpha release mainly contains updates to several of our Tor Browser components: Firefox got updated to 45.8.0esr, Tor to 0.3.0.4-rc, OpenSSL to 1.0.2k, and HTTPS-Everywhere to 5.2.11.

Additionally, we updated the bridges we ship with Tor Browser and fixed some regressions that came with our last release.

In the previous release we introduced filtering of content requests to resource:// and chrome:// URIs in order to neuter a fingerprinting vector. This change however breaks the Session Manager addon. Users who think having extensions like that one working is much more important than avoiding the possible information leakage associated with that can now toggle the 'extensions.torbutton.resource_and_chrome_uri_fingerprinting' preference, setting it to 'true' to disable our defense against this type of fingerprinting.

Another known regression is the resizing of the window. We are currently working on a fix for this issue.

The full changelog since Tor Browser 7.0a1 is:

  • All Platforms
    • Update Firefox to 45.8.0esr
    • Tor to 0.3.0.4-rc
    • OpenSSL to 1.0.2k
    • Update Torbutton to 1.9.7.1
      • Bug 21396: Allow leaking of resource/chrome URIs (off by default)
      • Bug 21574: Add link for zh manual and create manual links dynamically
      • Bug 21330: Non-usable scrollbar appears in tor browser security settings
      • Bug 21324: Don't update NoScript button with timer update
      • Translation updates
    • Update HTTPS-Everywhere to 5.2.11
    • Bug 21514: Restore W^X JIT implementation removed from ESR45
    • Bug 21536: Remove scramblesuit bridge
    • Bug 21342: Move meek-azure to the meek.azureedge.net backend and cymrubridge02 bridge
    • Bug 21348: Make snowflake only available on Linux for now
  • Linux
    • Bug 21326: Update the "Using a system-installed Tor" section in start script
  • Build system
    • OS X
      • Bug 21343: Remove unused FTE related parts for macOS
    • Linux
      • Bug 17034: Use our built binutils and GCC for building tor
      • Clean-up

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

11:25:23.157 no element found moz-nullprincipal:{70ca31a6-2f3f-4e4b-8450-24cf68d8210f}:1:1

12:32:53.433 : Component returned failure code: 0x805e0007 [nsIWebNavigation.loadURI] viewSource-content.js:349:0

https://check.torproject.org/torcheck/img/tor-on.png
12:27:15.751 Public-Key-Pins: An unknown error occurred processing the header specified by the site. tor-on.png

Torbutton INFO: Updated NoScript status for security settings
when switching tabs in NoScript Options

https://www.ssllabs.com/ssltest/analyze.html?d=aus1.torproject.org&s=2001%3a858%3a2%3a2%3aaabb%3a0%3a563b%3a1e28&latest
Images with "+" sign are not working after, probably, circuit is broken.

I updated 7.01 to 7.02
Torbirdie still does not find a connection, stable works fine

Set Torbirdy to Transparent Torification and then it should work. It does in my case

This is because we still have not fixed the underlying bug: https://trac.torproject.org/projects/tor/ticket/20761. This is scheduled for the next alpha release, though.

If you hit the Help ==> About the window of the version opens up.
If you hit new identity on the main window the help/about/version window remains open. Is this an issue? Will cookies and fingerprints carry over if by mistake it has been forgotten open?

We currently believe this is not an issue. However, as you indicate, this is highly confusing. We have https://trac.torproject.org/projects/tor/ticket/10952 to fix that.

Please, remove debug compiler flag -g from stable versions.

Hm, why? Mozilla is doing the same in the official releases.

WHAT??? https://trac.torproject.org/projects/tor/ticket/21448#comment:2
Never use debug tools for production. It's obvious.
Even if you think that Mozilla does - Mozilla and security are incompatible things.
Also see GCC 5.1 bugs with -g, you will be surprised.

17:10:36.500 TypeError: can't access dead object
Stack trace:
WalkerActor<.documentElement<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/inspector.js:1584:1
actorProto/ resource://devtools/server/protocol.js:1013:19
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:87:14
makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:87:14
1 protocol.js:907

17:10:36.600 Protocol error (unknownError): TypeError: can't access dead object1 Promise-backend.js:936

when trying to connect, but security connection failed immediately.

HAR (DevTools warn that connection wasn't secure!):
{
"log": {
"version": "1.1",
"creator": {
"name": "Firefox",
"version": "45.8.0"
},
"browser": {
"name": "Firefox",
"version": "45.8.0"
},
"pages": [
{
"startedDateTime": "2017-03-09T17:10:31.552+00:00",
"id": "page_1",
"title": "Problem loading page",
"pageTimings": {
"onContentLoad": -1,
"onLoad": -1
}
}
],
"entries": [
{
"pageref": "page_1",
"startedDateTime": "2017-03-09T17:10:31.552+00:00",
"time": 547,
"request": {
"bodySize": 0,
"method": "GET",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1238079",
"httpVersion": "",
"headers": [
{
"name": "Host",
"value": "bugzilla.mozilla.org"
},
{
"name": "User-Agent",
"value": "Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0"
},
{
"name": "Accept",
"value": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
},
{
"name": "Accept-Language",
"value": "en-US,en;q=0.5"
},
{
"name": "Accept-Encoding",
"value": "gzip, deflate"
},
{
"name": "Referer",
"value": "https://groups.google.com/forum/?_escaped_fragment_=topic/firefox-dev/WV2XkVN3sWQ/discussion"
},
{
"name": "Cookie",
"value": "_ga=GA1.2.123456789.1489123456; Bugzilla_login_request_cookie=dYUoo5667A; github_secret=a34567FgHjkl89cB"
},
{
"name": "Connection",
"value": "keep-alive"
}
],
"cookies": [
{
"name": "Bugzilla_login_request_cookie",
"value": "dYUoo5667A"
},
{
"name": "_ga",
"value": "GA1.2.123456789.1489123456"
},
{
"name": "github_secret",
"value": "a34567FgHjkl89cB"
}
],
"queryString": [
{
"name": "id",
"value": "1238079"
}
],
"postData": {
"mimeType": "",
"params": [],
"text": ""
},
"headersSize": 527
},
"response": {
"status": 0,
"statusText": "",
"httpVersion": "",
"headers": [],
"cookies": [],
"content": {
"mimeType": "text/plain",
"size": 0,
"encoding": "base64",
"text": ""
},
"redirectURL": "",
"headersSize": -1,
"bodySize": -1
},
"cache": {},
"timings": {
"blocked": 0,
"dns": 0,
"connect": 547,
"send": 0,
"wait": 0,
"receive": 0
}
}
]
}
}

Update to the previous post:
It's definitely a Tor Browser issue that "Try Again" button on Secure Connection Failed page doesn't trigger making a new circuit for the current site (as previous was lost). (Because opening the same site in a new tab does which also fixes the issue ("Try Again" starts to work.)
(Note: Reloading the page with devtools still breaks FPI.)

"Try Again" should not per se use a new Tor circuit. That's what "New Circuit for this Site" in the onion button menu is for. But maybe I am misunderstanding you. Could you elaborate where the '"Try Again" starts to work' comes into play? Is the issue that the "Try Again" button is broken or that it does not use a new circuit? Or both? Or...?

Huh. For every update/refresh/reload/hyperlink/etc of the tab Tor Browser automatically change a circuit when it was lost/broken/unresponsive/etc. But sometimes Tor Browser breaks (only secure?) connection to the site immediately (first bug) from the hyperlink, and this site was already opened for a long time in other tabs too, in this case (in log). And no refresh/F5/"Try Again" button can help (second bug), but any action in other tabs with this site triggers Tor Browser to make new connections and change the circuit until it finds a working one.

It could be, because of
[03-14 19:32:46] Torbutton INFO: controlPort >> 650 STREAM 650 CLOSED 99 63.245.215.80:443 REASON=END REMOTE_REASON=CONNRESET

Bug:
- enter one bridge: it works
- replace it with one other bridge: many error messages
"[warn] Failed to find node for hop 0 of our path. Discarding this circuit."

- to work with bridges again, need to put back first bridge (to get "listed=1"), or erase manually its "Guard" line in state file (with "unlisted_since=..." and "listed=0"), after connecting directly (and thus erasing parameters).

Not all symbols are visible on https://www.mozilla.org/en-US/firefox/organizations/all/

06:39:35.082 A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

Date: Sat Mar 11 2017 06:39:27 GMT+0000 (UTC)
Full Message: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [imgIRequest.image]
Full Stack: JS frame :: chrome://browser/content/content.js :: PageInfoListener.serializeElementInfo :: line 1189
JS frame :: chrome://browser/content/content.js :: PageInfoListener.getMediaNode/addImage :: line 1082
JS frame :: chrome://browser/content/content.js :: PageInfoListener.getMediaNode :: line 1116
JS frame :: chrome://browser/content/content.js :: PageInfoListener.processFrames :: line 1058
JS frame :: resource://gre/modules/Task.jsm :: TaskImpl_run :: line 315
JS frame :: resource://gre/modules/Task.jsm :: TaskImpl :: line 276
JS frame :: resource://gre/modules/Task.jsm :: createAsyncFunction/asyncFunction :: line 250
JS frame :: resource://gre/modules/Task.jsm :: Task_spawn :: line 164
JS frame :: chrome://browser/content/content.js :: PageInfoListener.getMediaInfo :: line 1033
JS frame :: chrome://browser/content/content.js :: PageInfoListener.receiveMessage :: line 9341 content.js:1189:0

19:31:42.244 TypeError: el.ownerDocument is null noscriptOverlay.js:2473:11

Now Tor Browser accesses \device\physicalmemory during startup, same as FF52 does, and crashes if denied. But why is it doing it? For https://www.computer.org/web/csdl/index/-/csdl/proceedings/cscwd/2009/3534/00/04968041.pdf ?

Have you filed a bug in Mozilla? Seems we should have this investigated at Mozilla's site.

OpenSSL to 1.0.1k
and
OpenSSL to 1.0.2k
referred in article. One reference is wrong. Please update article.

Done.

Look how Adobe works with Mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=1325592#c9
Could you ask them to add anti-fingerprinting and proxy-obedience features to private browsing mode?

[03-14 19:39:44] Torbutton DBUG: Got timer update, but no cookie change.
every minute, is OK?

Yes.

Dear Tor Project:
Stop intentionally making download signature verification difficult.

According to https://blog.torproject.org/blog/tor-browser-numbers
1. There are 100,000 downloads of Tor Browser per day.
2. But only 5000-7000 signature verification is done per day.

93%-95% Tor Browser downloads remains unverified at all.
This is because users only have 2 options:
1. Use GPG to verify and expose their true IP.
2. Not verify at all.

Proper checksums for unsigned raw download has been requested many times, but everytime Tor Project response with the same excuse with a stuck up attitude:
"What if Tor Project get hacked and you download the wrong sig?"

Listen, this is only a valid excuse for providing a better method (The GPG method), this is not a valid excuse for not providing even basic sha256/sha512 checksum at all, because they're not mutually exclusive, you can check both.

Look around, from Linux OSes to bitcoin software, everyone provide sha256 checksums. Somehow Tor Project think they are better than everyone dispite a dismal 95% unverified rate. Worse, they have a head-in-the-sand attitude regarding this basic but critical matter.

What Tor Project need to do:
1. Provide sha256/512 checksum for the raw download like everyone else.
2. Make GPG signature verification easy, and possible over tor itself, current guide doesn't cover how to use GPG to verify over tor, thus expose your true IP.

Tor Project developers, stop thinking in ideals and look at the reality.
Take your head out of the sand and actually look at what is happening (95% downloads not verified), not what you want to happen (everyone use GPG to verify).

If Tor Project can't do that, then stop pretending you guys care about user's security and anonymity.

You are already getting that for Linux bundles by default. Even for Windows you don't need GPG if you just want to check the provided SHA-256 sums (you need to strip the authenticode signature first but we have a guide for that on our signature verification page). So, OS X users are remaining then. But it seems to me that does not account for the gap between downloads/sig downloads. Moreover, we are working on that trying to provide tools to strip the signature and getting the same SHA-256 sum as the unsigned .dmg file.

Still being able to check the SHA-256 hash alone is not really more secure than just downloading the bundle and running it.

Post new comment

  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <em> <strong> <cite> <code> <ul> <ol> <li> <b> <i> <strike> <p> <br>

More information about formatting options

Syndicate content Syndicate content