Discontinuing the hardened Tor Browser series
When we started with the hardened Tor Browser series 18 months ago, we had two main purposes in mind:
- It should give users an even more secure Tor Browser, especially at higher security levels where JavaScript is partially or completely disabled.
- It should help us to identify issues earlier, therefore allowing to develop and backport fixes to the Tor Browser alpha and stable series.
The hardened series was a non-stable series on purpose, aimed at experienced users. The reason for that was not only the heavy performance impact of the hardening and debugging features we deployed. Rather, the impact of mixing both in Tor Browser seemed to be not well understood either: for example, does compiling Tor Browser with Address Sanitizer really lead to a more secure browser, given that the sanitizer is mainly intended as a debugging tool? Moreover, just using the hardening options provided by the toolchain seemed to be an incomplete solution to the problem—a bandaid until we could provide a more complete approach to hardening.
Looking again at its purposes above, we think it is safe to say that the hardened series indeed helped us identifying issues early on: with it we found bugs both in Firefox and tor and they got resolved quickly.
The picture is not so clear with respect to the promised security benefits. Part of the problem is that "more secure" can mean a wide variety of things. Another part is that we did not measure if we were indeed adding a security benefit to Tor Browser with all the techniques we deployed. What we learned over the course of the past 18 months, however, is that enabling expensive hardening can aid in making Tor Browser crashes much more reliable.
But that's not the only thing we learned. It seems we underestimated the confusion among users caused by labeling the series as "hardened" while at the same time including features for debugging purposes as well. The resulting experimental character of this series made it hard for users to decide whether that's actually the Tor Browser they wanted to have or not.
Where does that leave us? We've decided to stop having a "hardened" browser series, and instead we'll provide separate tools for the two purposes that it aimed to solve:
Users that are currently on the hardened update channel will get an update to the most recent Tor Browser alpha with a note to use Sandboxed Tor Browser instead for enhanced security. While the Sandboxed Tor Browser is currently in an experimental state itself, we feel that it provides much better safeguards against exploitation than the features we shipped in the hardened series.
Having Sandboxed Tor Browser for hardening the browser experience allows us to do an even better job with finding problems earlier in our Tor Browser patches or code in Tor Browser generally: we can include more debugging aids into special debug builds. We plan to do so and get back to dedicated debug nightly builds when we switch to our reproducible builds manager (rbm), which is happening soon.
Finally, thanks to all users of the hardened Tor Browser series. We hope Sandboxed Tor Browser and the upcoming debug builds will provide an even better match to your needs. If not, please make sure to file a bug in our bug tracker and we'll look into it.
Comments
Please note that the comment area below has been archived.
For me the main
For me the main characteristic of the hardened series was that it included Selfrando, is there a plan to make it land in alpha?
I'd like to know if the
I'd like to know if the window margins will be included as well?
There's a ticket for
There's a ticket for integrating Selfrando into the alpha Linux builds (and hopefully to the stable release then)
#20683 - Integrate selfrando into the alpha Linux 64bit builds
https://trac.torproject.org/projects/tor/ticket/20683
It would have been in the
It would have been in the 7.0a3 alpha if we had not found last minute issues with selfrando and the switch to ESR52. It is planned to have it in 7.0a4 for 64bit Linux.
When will you remove
When will you remove debugging information (-g) from release versions?
Hm. We are building Tor
Hm. We are building Tor Browser the same way as Mozilla does it seems or are you saying the Mozilla bundles are not built with -g? That said we are stripping all the symbols to provide separate debug archives for investigating crashes. So, what exactly is added and problematic in our case if we follow Mozilla in that regard?
Are you saying that building
Are you saying that building with and without -g gives you the same binaries because of stripping?
ac_add_options
ac_add_options --disable-debug-symbols
is what you need.
Will miss the hardened
Will miss the hardened series.
Used it with firejail
And yes, Where is selfrando?
It missed the 7.0a3
It missed the 7.0a3 deadline due to issues with the switch to ESR52 but should be back in 7.0a4.
Just a tip, maybe don't make
Just a tip, maybe don't make it so hard for people to find the link to the binaries of the sandboxed browser... :) (ie maybe put a link on https://www.torproject.org/download/download-easy.html.en or at least https://www.torproject.org/download/download.html.en instead of [1])
Tor Browser Sandbox
[1] https://www.torproject.org/projects/torbrowser.html.en#downloads
Thanks. This is currently
Thanks. This is currently still experimental software but once we think it has stabilized enough it will for sure get a more prominent position on our download page(s).
Seconding the prior
Seconding the prior comment... Sandboxing is a good addition, but it is not a "better match to our needs". It does not replace the memory exploit defenses (Selfrando), it only hopes to contain the exploit, once it was allowed due to the weak memory defenses.
It's like treating the symptoms of a problem... Please consider dealing with the cause - include the defenses (Selfrando) in the Sandboxed version?
There's a ticket for
There's a ticket for integrating Selfrando into the alpha Linux builds (and hopefully to the stable release then)
#20683 - Integrate selfrando into the alpha Linux 64bit builds
https://trac.torproject.org/projects/tor/ticket/20683
The idea is not to sacrifice
The idea is not to sacrifice selfrando (or whatever similar means come to mind) for sandboxing. Sandboxed Tor Browser is pretty much agnostic to whatever Tor Browser version it is used with (it lets you select on which channel you want to be at start-up). All in all we still think that the current sandboxing code for Linux makes it less likely that a user gets exploited compared to using the hardened version. Sure, we can make the result even better by shipping selfrando to alpha (and later stable) users and that is planned and currently worked on.
I am currently using a Tor
I am currently using a Tor Browser that is sandboxed, but the sandbox is on the hardened channel. about:tor still shows that I have 7.0a2-hardened. Will I/have I obtained the update to 7.0a3 not hardened
Update on previous
Update on previous comment:
7.0a3 was published to the sandbox but it refused because it was considered a downgrade. Bugs anyone?
> Bugs anyone? If the
> Bugs anyone?
If the behavior on 0.0.6 is anything but "detect that a hardened bundle is present, force a reinstall", then that's a bug.
If the sandbox code is anything older than that, I assume stuff breaks, because the sandbox handles updates somewhat differently from Tor Browser, and the code doesn't ever really expect channels to go away.
Okay, just deleted my old
Okay, just deleted my old configs and moved to TOR browser stable
Even after a clean install,
Even after a clean install, the Sandboxed TB's Preferences don't look normal. All the checkboxes look empty, and stay empty after clicking on them. So, after a while it's hard to know what options are in the "checked state" and what aren't. Decided to reinstall and then left the checkboxes alone.
Funny - hope they are selected right. :-)
That's a new one for me, and
That's a new one for me, and I haven't seen that on any of the systems I've tested the code on. Though I'm not surprised that the UI can randomly break, especially considering I'm not really a UI programmer.
`sandboxed-tor-browser` follows the XDG Base Directory Specification, and writes a JSON format config file to a standard location (`$XDG_CONFIG_DIR/sandboxed-tor-browser/sandboxed-tor-browser.json`), so it should be easy to check what's actually set.
nb: While human readable, any/all bugs relating to "I edited it and it broke" will be ignored.
Does the alpha provide
Does the alpha provide better security than regular tbb?
Vice versa
Vice versa
What you can be sure about:
What you can be sure about: The sandbox provides better security than both regular and alpha tbb.
- No sound at all - after
- No sound at all - after the switch from hardenen TB to the latest standardTB,
So maybe you should warn users about this and not do the upgrade that was pushed today , if sound is very important to them,
warn in the popup that the users will lose all kind of sound in Linux, in all kind of dists that uses ALSA / jack instead of pulse-audio. It does not seems possible to fix this in Firefox now for us users :- ( should we go back to the 51-series?
what is your plan to re-enable sound on the web for TB in the future? (pulse audio can not be used for many reasons, security might also be one of them)
This is the only clue an user gets when an audio stream or html5-media with sound tries to start, a popup that says..:
https://support.mozilla.org/1/firefox/52.1.0/Linux/en-US/fix-common-aud…
Thank you for you work with TB and firefox
> what is your plan to
> what is your plan to re-enable sound on the web for TB in the future?
I don't think it's reasonable to expect the Tor Browser developers to maintain an audio backend that has been deprecated upstream, that will slowly rot away due to lack of developer attention.
https://bugzilla.mozilla.org/show_bug.cgi?id=1247056
is it really a big problem
is it really a big problem to support that?
Alsa seems to be in the kernel, and also pulse audio
seems to be just an extra risk-layer on top on Alsa (?)
I can understand that it is preferred to use only one
method, if it is true that no one cares
but pulse audio seems to me like a potential big risk and not worth it.
+adding a lot of junk to many the slim distros.. to do the same job
No telemetry? No sound! (c)
No telemetry? No sound! (c) Mozilla
Maybe it would have been
Maybe it would have been better to wait until selfrando and sandboxing are stable and available before discontinuing the hardened builds? The current alpha version is almost unusable (downloading a file crashes the browser).
The version(s) of SelfRando
The version(s) of SelfRando that shipped with the `hardened` code had some "interesting" defects. The newer code is supposed to be better.
FWIW, sandboxing is version agnostic and works with the release bundle. While each person's experience will vary, it works well for my use cases, and has been all I use since the moment it started compiling. That said, I am biased, and it does break certain things, YMMV.
Too bad I only have a x86
Too bad I only have a x86 processor and no one that can run 64bits systems, will never have the opportunity to use the sandbox :/
I have great news. The
I have great news. The deprecation of the `hardened` channel does not affect you at all, because you couldn't use that either.
Anonymous wants 32-bit
Anonymous wants 32-bit sandbox, and you're joking at him :)
Don't worry, I know that he
Don't worry, I know that he has valid reasons to not support it https://bugs.torproject.org/20940, wont blame him :P (but that doesn't change the fact that I will be sticking with this 86 processor for the rest of my life)
Rather random thought: f I
Rather random thought: f I am to use a stable intergrated sandboxed Tor browser in the future, is there a reason to use firejail on top of it?
"sandboxed" may mean
"sandboxed" may mean different things here. Firefox 52 which Tor Browser 7.0 will be based upon ships with content sandboxing which should make it harder to exploit vulnerabilities found in the browser. Then there is Sandboxed Tor Browser for Linux 64bit users that is using bubblewrap to provide a process-wider sandbox. In it you can run any Tor Browser series, be it the stable one, the alpha one or some nightly build.
So, I assume you mean "content sandboxing" when talking about "sandboxed". In that case I'd say there are good reasons to use process-wide sandboxing in combination with it. We'd recommend Sandboxed Tor Browser for that, though.
There's design reasons why
There's design reasons why `sandboxed-tor-browser` is a separate executable. I don't see "integration" happening without a considerable amount of redesign in how Tor Browser works.
I personally think it's pointless to combine the bubblewrap based sandbox (`sandboxed-tor-browser`) with firejail, assuming that sort of configuration even works (and I suspect it won't), because of the amount of overlap between the feature sets.
As a journalist in my
As a journalist in my country, I feel the security tor provides is necessary. But I'm far from an advanced tor user or developer. Should I be using the hardened alpha over the standard browser? "Alpha" is intimidating and sounds highly unstable. What should I do?
What is your system? If
What is your system? If you're using Linux 64 you should be using the sandbox which provides much more security.
You shouldn't be using the (now) discontinue "hardened alpha" since it is more designed for people who want to debug and find bugs.
problem with recent tor
problem with recent tor browser for windows........seems kind of defunt. doesn't really work taht stable and fails to load website....something wrong?
Was the discontinuation of
Was the discontinuation of the experimental hardened browser completely at your discretion, or were you approached by any government entities that may have taken issue?
It was just us. You can read
It was just us.
You can read the history of the ticket at:
https://trac.torproject.org/projects/tor/ticket/20814
And some cypherpunks ;)
And some cypherpunks ;)
You count as part of us. ;)
You count as part of us. ;)
"Alpha" is intimidating and
"Alpha" is intimidating and sounds highly unstable. What should I do?"
You shouldn't use alpha.
(This easy answer was so many times misunderstood, because "hardened" looked like a better product without stable version. Thanks for removing it.)
I am pleased that some
I am pleased that some clarity will come to the different versions as many that use TOR are not familiar with some of the geeky terms such as "Sandboxing". It has always been a problem that certain aspects of using TOR at maximum safely has been obscure on this group itself and one has had to go to other sites to find out what tweaks can be done to improve security. For example, i see on the latest version we still have all these links to google in the about:config page. Would there not be a way to delete anything to do with google perhaps in the security settings?
Thanks for your work
Hey there, it's Tor not TOR
Hey there, it's Tor not TOR ;)
https://www.torproject.org/docs/faq.html.en#WhyCalledTor
I see that mistake quite
I see that mistake quite commonly with those who use Tor for less legitimate purposes. Not a real survey though.
What about jemalloc on all
What about jemalloc on all platforms?
What about it? Firefox and
What about it? Firefox and thus Tor Browser is currently using it on Windows, macOS, Linux.
Joking? Firefox uses
Joking?
Firefox uses --enable-jemalloc to enable that on Windows.
See https://trac.torproject.org/projects/tor/ticket/21448#comment:2
Oh, thanks. It seems we
Oh, thanks. It seems we don't use jemalloc on Windows as we are building with mingw-w64. Might be worth thinking about whether we should.
"With regard to jemalloc in
"With regard to jemalloc in Firefox 3, the primary reason it was worthwhile was the horrible fragmentation behavior of the malloc implementations on Windows."
https://lwn.net/Articles/273001/
"Our automated tests on Windows Vista showed a 22% drop in memory usage when we turned jemalloc on."
https://stackoverflow.com/questions/1624726/how-does-jemalloc-work-what…
"in 2010 Mozilla sponsored
"in 2010 Mozilla sponsored integration of Apple Mac OS X support into the stand-alone jemalloc, and in 2012 contributed MinGW Windows support."
https://github.com/jemalloc/jemalloc/wiki/Background
Yes, but what breaks is
Yes, but what breaks is enabling jemalloc when using mingw-w64 to cross-compile Tor Browser. I guess using it to build on Windows is working. But I have not tested that.
What does Tom Ritter think?
What does Tom Ritter think?
Seems he is cross-compiling
Seems he is cross-compiling well.
"Memory used by the system
"Memory used by the system allocator that is currently allocated to the "
"application. This is distinct from the jemalloc heap that Firefox uses for "
"most or all of its heap allocations. Ideally this number is zero, but "
"on some platforms we cannot force every heap allocation through jemalloc.");
I hope you do not. Jemalloc
I hope you do not. Jemalloc is quite insecure (though at least it doesn't use deprecated APIs like sbrk like ptmalloc does...), whereas the native windows memory allocator is exceptionally well hardened, beyond the native malloc in glibc (ptmalloc and dlmalloc), or even the openbsd libc. Really the only downside it has is the Fault Tolerant Heap, and even that is not a big issue for a browser. The fact that jemalloc is not used on Windows makes Firefox significantly more hardened on that platform.
I didn't know that vanilla Firefox used --enable-jemalloc on Windows, though. I was under the impression that, like Tor Browser, it used the system malloc on Windows systems. I'll add that to my notes of security advantages Tor Browser has over regular Firefox for those who are under the impression that it is just Firefox + Tor!
Also what about using
Also what about using jemalloc in Tor?
Using jemalloc for Tor would
Using jemalloc for Tor would be silly. Not only is jemalloc one of the least secure allocators due to large, aligned 2 MiB heaps, but it really is only useful for improving performance on highly multithreaded programs, like database servers and multithreaded browsers. Tor, which is rather infamously limited by its single work thread, would not benefit in the least from jemalloc.
Go and use copperhead bionic malloc or openbsd malloc and then we're talking. :P
Where are build instructions
Where are build instructions so we can compile it ourselves?
You mean the sandboxed Tor
You mean the sandboxed Tor Browser or Tor Browser? For the former see: https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tre…
and there is a Makefile. For the latter see: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/giti… and our hacking guide: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking.
I'm concerned that only one
I'm concerned that only one person is working on sandboxed-tor-browser. How can I help without being a coder? Can I make donations directly to the sandboxed-tor-browser to the developer to help?
From what I've heard, this
From what I've heard, this single person's funding for this project has also run out, so they are also no longer going to work on it full time. I'm not sure if this means it will go into maintenance hell, or if it'll be picked up by other people. I think you should go ask on #tor-project on OFTC about directly donating to that project.
It gets bug fixes. I'm not
It gets bug fixes. I'm not really doing new feature development or gigantic improvements, and the code is basically at the point where security improvements will require patching firefox, and usability improvements require fighting with D-Bus and doing UI code.
I'm also not in a position to be able to accept individual donations.