Selfrando: Q and A with Georg Koppen
Georg Koppen is a longtime Tor browser developer. He and Tor developer Mike Perry worked to integrate Selfrando into Tor browser.
Tell us about Selfrando, the new code being tested for Tor Browser.
Selfrando randomizes Tor browser code to ensure that an attacker doesn't know where the code is on your computer. This makes it much harder for someone to construct a reliable attack--and harder for them to use a flaw in your Tor Browser to de-anonymize you.
How were you and Tor's Mike Perry involved in the project?
We mainly worked on integrating Selfrando in Tor Browser where needed and tested it as well as we could. We closely read the paper and helped to improve it. The bulk of the work was done by the other researchers. These are Mauro Conti, Stephen Crane, Tommaso Frassetto, Andrei Homescu, Per Larsen, Christopher Liebchen, and Ahmad-Reza Sadeghi.
Can you talk about Tor's relationship with the research community?
Tor relies on the research community to ethically investigate unsolved issues with Tor software. We work closely with research groups in the anonymity space, the security space, in privacy research, etc.
Tor is the focus of many researchers. We have rigorous documentation and open, transparent development processes. We also have a working product, Tor Browser, that easily reaches 1 to 2 million users, with testing channels where one can try new defenses first and refine them as needed, as we are doing with the Selfrando project.
When will Selfrando be available for ordinary Tor users (in the stable version)?
The first thing to note here is that Selfrando is currently only available for a fraction of our users; those who have a 64-bit Linux systems. The Selfrando folks are working on a version for Windows which is not yet ready.
I think that Tor browser version 6.5 might be a bit too early for a stable release. However, if user testing shows this is okay, Selfrando will make it in. A more conservative approach is pointing to Tor browser version 7.0.
That’s a pretty long time from now (next Spring!) How can people help Tor speed it up?
We need more users testing things--more experienced people trying out our nightly/alpha builds.
Selfrando's development is good so far and the browser integration work has not been so tricky; the main problem is being confident enough that it does not break some random user setups while everything is fine and working on our testing machines.
Specifically, we need more experienced people running Linux 64-bit operating systems to download and try our hardened nightly builds. They can download the latest hardened nightly build and look for the latest "nightly-hardened" build in general at https://people.torproject.org/~linus/builds/. Obviously, these are test versions of the Tor Browser--we're trying to look for bugs.
Will there will be future collaborations with these researchers?
To port Selfrando to Windows and OSX and make it available to our users, yes!
How do you feel about the fact that the research community is teaming up with Tor to strengthen Tor browser against attacks?
I think this is great as it gives us another valuable ally to make our users safer. And in the longer run, all other users with "normal" browsers could benefit from that, too.
______________________________________________________________
The researchers behind Selfrando will present their project in July at the Privacy Enhancing Technologies Symposium in Darmstadt, Germany.
An advance copy of their research paper is available here.
Selfrando is available for use in other open-source projects on Github.
Comments
Please note that the comment area below has been archived.
Very nice, I hope that this
Very nice, I hope that this will help Tor be more secure, I give my best wishes to the creators, thanks.
-Anonymous
Hi, will stock Firefox also
Hi,
will stock Firefox also use Selfrando? And what about Firefox packaged by distros like in e.g. Debian?
Thanks
Not sure yet. I at least am
Not sure yet. I at least am hoping that vanilla Firefox users will benefit from this technique as well sooner than later.
How about other programs?
How about other programs? When we'll see it as a flag in most of toolchains, like aslr/dep are?
gk has been doing a good job
gk has been doing a good job so far keep it up
This is great news! Over
This is great news!
Over the next 5-10 years for Tor to have any hope of frustrating the Police states everywhere consistently, it would appear several things are needed:
1) TBB patches are accepted upstream by Mozilla
2) The network loses dependence on anonymous guard/relay/exit nodes that are regularly poisoned and used in numerous forms of de-anonymization attacks by malicious actors
3) The network is scaled up in the order of several multiples
4) Quantum-resistant ciphers are used
5) A solution is found to the problem of global adversaries who control internet exchange points and autonomous systems. Perhaps a company might offer a million dollars for any group of researchers who can solve this problem outlined below in a practical fashion:
http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf
"The results show that Tor faces even greater risks from traffic correlation than previous studies suggested. An adversary that provides no more bandwidth than some volunteers do today can deanonymize any given user within three months of regular Tor use with over 50% probability and within six months with over 80% probability.
Some of our results against an adversary controlling ASs or IXPs are similarly alarming. Some users experience over 95% chance of compromise within three months against a single AS or IXP."
6) Users are educated in using Tor in hardened virtualized systems only. They should understand that they will be the focus of frequent attacks in the wild and should assume they will be hacked at the browser/network level in due course. Solutions like Qubes, Whonix, and Subgraph O/S pose much promise in this space i.e. isolated, hardened, instances of Tor running in (mostly) read-only application VMs.
Keep up the great work!
Many, many thanks for
Many, many thanks for this!
I consider myself "more experienced", yet looking at the hardened build directory leaves me confused. What do those archives contain? What do I need to download? Why is there no signature file for the *xz archive?
Some instructions (a README) would be much appreciated.
Good idea--I'll mention it
Good idea--I'll mention it to Georg.
> We need more users testing
> We need more users testing things--more experienced people trying out our nightly/alpha builds.
>
> Selfrando's development is good so far and the browser integration work has not been so tricky; the main problem is being confident enough that it does not break some random user setups while everything is fine and working on our testing machines.
Just to clarify: "experienced people" means people experienced using stable Tor Browser to surf, not neccessarily experienced debuggers, right?
If so, I can try to help, but could use some instructions on reporting any bugs. Anonymously of course (so listserves are out).
"Experienced people" does
"Experienced people" does merely mean users that are willing to try non-stable Tor Browser versions and, ideally, reporting bugs. And, no, no debugger experience is needed. :)
About reporting bugs: You can use our bug tracker (https://trac.torproject.org) with an anonymous account. See the "Unofficial Documentation" section for a how-to. Otherwise showing up on IRC in #tor-dev on irc.oftc.net should work as well or sending email to Tor Browser folks.
Probably best to reword the
Probably best to reword the blog post to reflect this. Wouldn't want to scare off any would be testers. The more the better as stated ; )
In https://people.torproject.
In
https://people.torproject.org/~linus/builds/tbb-nightly-hardened-2016-0…
I see
o tor-browser-linux64-tbb-nightly-hardened_ALL.tar.xz
o sha256sums-unsigned-build.txt
o sha256sums-unsigned-build.txt.asc
So I think the idea is that users with a 64bit Linux system should
o download all three of those
o obtain the correct signing GPG key
o verify the signature of the file holding the SHA256 hashes
o verify that tarball (the tar.xz archive) has the stated SHA256 hash
o unpack the tarball
o surf until you find some bugs
o report all bugs
If I misunderstood, then I am sure I am not the only one.
Yes, thanks for the
Yes, thanks for the write-up. One additional thing: the key is https://people.torproject.org/~linus/builds/Continuous-TBB-builds-4D0DB…
A FAQ for how to help with
A FAQ for how to help with testing would be good, too....
Stuff like bug reporting procedure, which mailing lists and irc channels are relevant, etc. I consider myself a more experienced *user* but don't really know where to begin with testing. Do I just replace my normal Tor browsing activity with browsing using the nightly (as long as I'm not in a high risk situation)?
Ideally, just using the
Ideally, just using the nightly instead is a good idea, yes. Unfortunately, we don't have a nightly update channel yet which makes keeping up-to-date a bit painful. We are working on it in https://bugs.torproject.org/18867.
Regarding bug reporting: I am happy about bug reports whichever medium you are preferring to use. We have our bug tracker (https://trac.torproject.org), we are usually hanging out in #tor-dev on irc.oftc.net if there are questions etc. There is a separate mailling list for Tor Browser development as well: tbb-dev and of course there are the individual mailing addresses for Tor people.
> We have our bug tracker
> We have our bug tracker (https://trac.torproject.org)
Can you post anonymously via Tails? Are unstructured bug reports ("I experienced this unexpected behavior and have no idea what caused it or whether it might be serious") useful, because this seems to be the only kind I can come up with. (Example: "seeing junk in gedit/file manager sidebars while using Tails, becomes readable when mouseover"; didn't realize at time of report that fact I was using 32-bit Tails on a 64-bit machine was probably relevant, that the likely cause was some slowdown in the crypto while accessing an encrypted USB stick.)
The structured forms are more for people who have read some of the code, I think.
> we are usually hanging out in #tor-dev on irc.oftc.net if there are questions etc.
Can Tails users still use irc.oftc anonymously via the Pidgin in Tails?
I am reluctant to expose myself for a one-off bug report of questionable utility (because I usually don't understand what I saw, sometimes not even sure I saw something real).
BTW, I think you may have been one of the people in Debian who understood years ago that Debian users were put at risk from state-sponsored hacking by unencrypted bug reports and popularity contest reporthttps://ocewjwkdco.tudasnich.de/blog/tors-innovative-metrics-program-receiv…; the Snowden leaks verified in detail that the fears expressed by some Debian users were not misplaced.
Thks again for replying! And for Selfrando!
You could use tor to create
You could use tor to create and access an account on the trac site used by devs to report bugs. @GK . A nice bug reporting guideline could help immensely. Informing new users of how to structure their reports and helping them think like testers. This guide should be pinned somewhere very noticeable in a relevant area.
Tails uses Whisperback,
Tails uses Whisperback, which even supports gpg-encrypted anonymous bug reports.
In case anyone reads old
In case anyone reads old comments like me right now, a caveat about Whisperback:
Most uniquely identifying information like network interface MACs are removed (i.e., "[MAC REMOVED]"), but the SSID of the wireless network you connected to still remains. Oops.
See for yourself. Open Whisperback, and copy and paste the 'debugging info' part (focus on it and use Select All or CTRL+A because there's too much text to select the whole lot) into Gedit and search for 'ssid'. Yet not only does the SSID remain, but for some reason one can't edit the debugging info anymore to remove it. Don't use Whisperback from home then!
I just checked this in TAILS 2.5 today.
Would be really nice and
Would be really nice and seamless if bug reporting were built into the test builds (in modular fashion). Maybe a second tool could run simultaneously to collect data about the browser. Like a supervisor. Omitting sensitive data while retaining things like what kind of elements loaded in the browser, what functions were called, etc. Users could opt out of using this observer tool any time they please. Could make testing more efficient.
And, after trying to verify
And, after trying to verify sha256sums-unsigned-build.txt.asc: Why is the key 4D0DB324 not present on standard keyservers? Downloading that from the same server as the software itself does not add much value, does it?
Except that if you check the
Except that if you check the signatures of 0xD1982B344D0DB324, you'll see that Linus Nordberg did sign it with his own key 0x1E8BF34923291265, which is available on pool.sks-keyservers.net. Linus' key is itself heavily signed.
The key is 'only' 2,048 bit. Maybe a new key in future that's 4,096 bit and with several signatures from other Tor Project people is more satisfying, but there's enough already, yes? Perhaps the bigger threat is that these 'bleeding edge' builds almost certainly have undiscovered bugs, even if the signatures are watertight.
Be careful what you browse when testing: innocuous stuff first, so that if you are compromised, it's not embarrassing! Reserve sensitive stuff for well-tested releases.
> Be careful what you browse
> Be careful what you browse when testing: innocuous stuff first, so that if you are compromised, it's not embarrassing! Reserve sensitive stuff for well-tested releases.
Will do.
Actually, a list of globally
Actually, a list of globally popular but fairly innocuous and not horribly unsafe websites would be helpful. If it comes from TP not CIA, of course....
Some system info: $ uname
Some system info:
$ uname -a
3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS"
First attempt:
Starting with tor-browser/Browser/start-tor-browser --verbose
chrashes, where these are the last log messages:
Jun 24 09:14:27.711 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Jun 24 09:14:27.000 [notice] Parsing GEOIP IPv4 file /home/torbrowser/tor-browser/Browser/TorBrowser/Data/Tor/geoip.
Jun 24 09:14:28.000 [notice] Parsing GEOIP IPv6 file /home/torbrowser/tor-browser/Browser/TorBrowser/Data/Tor/geoip6.
Jun 24 09:14:29.000 [notice] Bootstrapped 0%: Starting
Jun 24 09:14:29.000 [notice] Delaying directory fetches: DisableNetwork is set.
[3809] ###!!! ABORT: X_ShmPutImage: BadShmSeg (invalid shared segment parameter); 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[3809] ###!!! ABORT: X_ShmPutImage: BadShmSeg (invalid shared segment parameter); 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
ASAN:SIGSEGV
=================================================================
==3809==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000414dd6 bp 0x7f28cde84a10 sp 0x7f28cde84a00 T37)
SRAT init
ASAN:SIGSEGV
==3809==AddressSanitizer: while reporting a bug found another one. Ignoring.
Jun 24 09:14:42.000 [notice] Monitored process 3809 is dead.
Jun 24 09:14:42.000 [notice] Owning controller process has vanished -- exiting now.
Jun 24 09:14:42.000 [notice] Catching signal TERM, exiting cleanly.
Second attempt:
Without --verbose a language chooser appears. It remains empty for a long
time. Display of "Next" and "close" buttons takes longer still.
The browser starts. The first thing I see is "WARNING: this browser is out of
date."
A check for updates via the onion results in: Update XML file not found (404)
Third attempt.
Again with --verbose. Starts properly, but out of date WARNING remains.
Seems to work. I’m on "High" security level now.
Thanks for testing. Do you
Thanks for testing. Do you hit the first crash again with a clean Tor Browser nightly hardened? In other words: is this reproducible?
Yeah, the warning is normal currently as we don't have an nightly update channel yet. We are working on it in https://bugs.torproject.org/18867.
Yes, that was with the first
Yes, that was with the first start of a clean install.
No, it's not reproducible. Today I got similar crashes twice again (from the previous installation directory, no new install):
Jun 28 08:53:29.000 [notice] New control connection opened from 127.0.0.1.
Jun 28 08:53:29.000 [notice] New control connection opened from 127.0.0.1.
[31474] ###!!! ABORT: X_ShmPutImage: BadShmSeg (invalid shared segment parameter); 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[31474] ###!!! ABORT: X_ShmPutImage: BadShmSeg (invalid shared segment parameter); 3 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
ASAN:SIGSEGV
=================================================================
==31474==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000040e800 bp 0x7f1d1d826240 sp 0x7f1d1d826230 T27)
SRAT init
ASAN:SIGSEGV
==31474==AddressSanitizer: while reporting a bug found another one. Ignoring.
On the third attempt, Tor Browser nightly started.
Interesting. Could you try
Interesting. Could you try the regular nightly build (on https://people.torproject.org/~linus/builds/ in the tbb-nightly-YYYY-MM-DD folder) and the hardened-alpha (https://oiyfgiixvl.tudasnich.de/torbrowser/6.5a1-hardened/) to rule out that selfrando is the culprit and test whether the Address Sanitizer is somehow involved?
Also the non-hardened
Also the non-hardened version tor-browser-linux64-tbb-nightly_ALL.tar.xz (2016-06-30) crashes from time to time (only directly upon startup):
Jul 01 15:59:06.000 [notice] New control connection opened from 127.0.0.1.
[6012] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[6012] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
Jul 01 15:59:07.000 [notice] Owning controller connection has closed -- exiting now.
Jul 01 15:59:07.000 [notice] Catching signal TERM, exiting cleanly.
/home/torbrowser/tor-browser/Browser/start-tor-browser: Zeile 372: 6012 Speicherzugriffsfehler (Speicherabzug geschrieben) TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox --class "Tor Browser" -profile TorBrowser/Data/Browser/profile.default "${@}" < /dev/null
Alright, thanks. Could you
Alright, thanks. Could you try getting a stack trace from the crash taking the *debug.zip from the same day and follow https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking (sections "Using gdb" + "Starting firefox from inside gdb"? Once it crashes "bt" should give you a stack trace we can inspect.
This is for the July 9
This is for the July 9 version.
Immediately after the run command I see (not sure whether the warning is relevant):
Starting program: /home/torbrowser/tor-browser/Browser/firefox -profile Browser/TorBrowser/Data/Browser/profile.default
warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
Note that for the first start I had to press "c" several times in the debugger.
Eventually I got this:
Jul 11 14:55:29.000 [notice] New control connection opened from 127.0.0.1.
Jul 11 14:55:29.000 [notice] New control connection opened from 127.0.0.1.
[New Thread 0x7fffc3aff700 (LWP 1315)]
[New Thread 0x7fffc22ff700 (LWP 1316)]
[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc74ff700 (LWP 1308)]
mozalloc_abort (
msg=msg@entry=0x7fffc74fd6cc "[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157")
at /home/debian/build/tor-browser/memory/mozalloc/mozalloc_abort.cpp:33
33 /home/debian/build/tor-browser/memory/mozalloc/mozalloc_abort.cpp: Datei oder Verzeichnis nicht gefunden.
(gdb) Jul 11 14:55:30.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Jul 11 14:55:30.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jul 11 14:55:30.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jul 11 14:55:30.000 [notice] Bootstrapped 100%: Done
(It wasn’t clearly visible that a gdb command prompt is available. Pressing
enter showed that it was, though.)
bt output:
#0 mozalloc_abort (
msg=msg@entry=0x7fffc74fd6cc "[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157")
at /home/debian/build/tor-browser/memory/mozalloc/mozalloc_abort.cpp:33
#1 0x00007ffff2199393 in Abort (
aMsg=0x7fffc74fd6cc "[1254] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago: file /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp, line 157") at /home/debian/build/tor-browser/xpcom/base/nsDebugImpl.cpp:452
#2 NS_DebugBreak (aSeverity=,
aStr=0x7fffc2ca6e58 "X_ShmAttach: BadAccess (attempt to access private resource denied); 2 requests ago", aExpr=0x0,
aFile=0x7ffff45066de "/home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp", aLine=157)
at /home/debian/build/tor-browser/xpcom/base/nsDebugImpl.cpp:439
#3 0x00007ffff37feeb3 in X11Error (display=0x7ffff69e9000, event=)
at /home/debian/build/tor-browser/toolkit/xre/nsX11ErrorHandler.cpp:157
#4 0x00007fffee6f354b in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007fffee6f05e7 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007fffee6f0695 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007fffee6f1578 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007fffee6ed0cd in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9 0x00007ffff332601b in nsShmImage::Create (aSize=..., aDisplay=0x7ffff69e9000, aVisual=, aDepth=)
at /home/debian/build/tor-browser/widget/nsShmImage.cpp:78
#10 0x00007ffff3326154 in nsShmImage::EnsureShmImage (aSize=..., aDisplay=, aVisual=,
aDepth=, aImage=...) at /home/debian/build/tor-browser/widget/nsShmImage.cpp:193
#11 0x00007ffff33376a8 in nsWindow::GetDrawTarget (this=0x7fffe931a750, aRegion=...)
at /home/debian/build/tor-browser/widget/gtk/nsWindow.cpp:6478
#12 0x00007ffff332db9b in nsWindow::StartRemoteDrawingInRegion (this=, aInvalidRegion=...)
at /home/debian/build/tor-browser/widget/gtk/nsWindow.cpp:6497
#13 0x00007ffff27a98a6 in mozilla::layers::BasicCompositor::BeginFrame (this=0x7fffdc280110, aInvalidRegion=..., aClipRectIn=0x0,
aRenderBounds=..., aClipRectOut=0x7fffc74fe860, aRenderBoundsOut=0x7fffc74fe840)
at /home/debian/build/tor-browser/gfx/layers/basic/BasicCompositor.cpp:552
#14 0x00007ffff27cadc1 in mozilla::layers::LayerManagerComposite::Render (this=this@entry=0x7fffc283af00, aInvalidRegion=...)
at /home/debian/build/tor-browser/gfx/layers/composite/LayerManagerComposite.cpp:795
#15 0x00007ffff27cb3b1 in mozilla::layers::LayerManagerComposite::UpdateAndRender (this=this@entry=0x7fffc283af00)
at /home/debian/build/tor-browser/gfx/layers/composite/LayerManagerComposite.cpp:389
#16 0x00007ffff27cb480 in mozilla::layers::LayerManagerComposite::EndTransaction (this=0x7fffc283af00, aTimeStamp=...,
aFlags=) at /home/debian/build/tor-browser/gfx/layers/composite/LayerManagerComposite.cpp:316
#17 0x00007ffff27e1503 in mozilla::layers::CompositorParent::CompositeToTarget (this=0x7fffc2aa8400, aTarget=aTarget@entry=0x0,
aRect=aRect@entry=0x0) at /home/debian/build/tor-browser/gfx/layers/ipc/CompositorParent.cpp:1160
#18 0x00007ffff27e160f in mozilla::layers::CompositorVsyncScheduler::ComposeToTarget (this=this@entry=0x7fffc3b22700,
aTarget=aTarget@entry=0x0, aRect=aRect@entry=0x0) at /home/debian/build/tor-browser/gfx/layers/ipc/CompositorParent.cpp:559
#19 0x00007ffff27e1674 in mozilla::layers::CompositorVsyncScheduler::Composite (this=0x7fffc3b22700, aVsyncTimestamp=...)
at /home/debian/build/tor-browser/gfx/layers/ipc/CompositorParent.cpp:440
#20 0x00007ffff235d205 in MessageLoop::RunTask (this=0x7fffc74fecf8, task=0x7fffc2ad89a0)
at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:364
#21 0x00007ffff2361101 in MessageLoop::DeferOrRunPendingTask (this=, pending_task=...)
at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:372
#22 0x00007ffff236120f in MessageLoop::DoWork (this=0x7fffc74fecf8)
at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:459
#23 0x00007ffff235d3e4 in base::MessagePumpDefault::Run (this=0x7fffd30de070, delegate=0x7fffc74fecf8)
at /home/debian/build/tor-browser/ipc/chromium/src/base/message_pump_default.cc:34
#24 0x00007ffff235d264 in RunHandler (this=) at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:227
#25 MessageLoop::Run (this=this@entry=0x7fffc74fecf8) at /home/debian/build/tor-browser/ipc/chromium/src/base/message_loop.cc:201
#26 0x00007ffff2367546 in base::Thread::ThreadMain (this=0x7fffd30f5a60)
---Type to continue, or q to quit---
at /home/debian/build/tor-browser/ipc/chromium/src/base/thread.cc:172
#27 0x00007ffff2363237 in ThreadFunc (closure=)
at /home/debian/build/tor-browser/ipc/chromium/src/base/platform_thread_posix.cc:36
#28 0x00007ffff7bc4184 in start_thread (arg=0x7fffc74ff700) at pthread_create.c:312
#29 0x00007ffff6c3a37d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
A million thanks to the
A million thanks to the Selfrando researchers and the Tor Browser team!
And special thanks to those Debian developers who are working for better security in Debian too.
Here are two news articles on Selfrando:
http://www.theregister.co.uk/2016/06/23/tot_project_selfrando/
Tor onion hardening will be tear-inducing for feds
Onion rings get more scrambled
Darren Pauli
23 Jun 2016
> ...
> It is hoped the technique described in the paper Selfrando: Securing the Tor Browser against De-anonymisation Exploits [PDF] will help to frustrate deanonymisation efforts by government agencies. Selfrando, currently under testing in hardened Tor versions, is described as an "enhanced and practical load-time randomisation technique" that defends against exploits, namely that allegedly used by the FBI.
>
> The [authors of the Selfrando paper] cite the 2013 attacks in which the FBI compromised Tor hidden services servers to deliver an exploit to de-anonymise users. The exploit abused an use-after-free vulnerability in Firefox to gain arbitrary code execution. "The main payload of the exploit collected the MAC address and the host name from the victim machine and sent the data to an attacker-controlled web server, bypassing Tor," they write. "That message also included a unique ID provided by the booby-trapped page in order to correlate a specific user to a specific visit."
https://motherboard.vice.com/read/tor-is-teaming-up-with-researchers-to…
Tor Is Teaming Up With Researchers To Protect Users From FBI Hacking
Joshua Kopstein
19 Jun 2016
> ...
> The new method is meant to counteract what's known as “code reuse” exploits, where rather than attempting the much harder task of injecting new malicious code, an attacker will exploit a memory leak to reuse code libraries that already exist in the browser—essentially, building malware by rearranging things inside the application's memory. To do that, an attacker generally needs to have an idea of where certain functions are located within the application's memory space. But the current security mechanisms in browsers only randomize the locations of code libraries, not the individual functions. Which is where the Selfrando technique comes in, creating a random address space for internal code that's much harder to exploit.
> The first thing to note
> The first thing to note here is that Selfrando is currently only available for a fraction of our users; those who have a 64-bit Linux systems.
Many people who use Linux use mostly 32-bit because that is what is available. Which may be why Tails does not offer 64 bit versions yet.
That said, any time =line on when the hardened browser may become standard in Tails?
Tails is still 32-bit to
Tails is still 32-bit to maintain compatibility with very old computers. Anyone who has installed Linux on a desktop this decade is most likely running with all 64 of the bits.
As a long time Tails user I
As a long time Tails user I actually support the design decision to offer 32 bit only for now because many users including me only have access to limited hardware. Many of the most endangered users live where only certain hardware is available.
Why not offer both 32 and 64 bit as does Tor for stable TBB? Presumably because that increases the workload and the chance for a bad mistake which can be exploited by our enemies.
Also, Tails devs obviously had to work very hard to rebase Tails on current Debian stable. This was important for many reasons and led to cleaning up much potentially dangerous cruft. Hopefully the next Debian rollover will not be such a challenge for Tails.
All that said, I very much want to see Selfrando and other hardenings incorporated in Tails ASAP. All like minded people: please consider contributing to Tails via FOTP foundation or another foundation which can route donations to Tails team.
Normal Tor Browser has many
Normal Tor Browser has many additional security features over Vanilla Firefox. The article says Selfrando will for the moment only be in Linux Testing version, it doesn't say it's restricted to the Hardened release. The difference between Hardened testing and normal testing is that Hardened uses Address Sanitizer (ASan.) ASan requires several times more memory and gives a significantly noticable slowdown. 32bit simply doesn't have the memory to use ASan in large applications, like a modern web browser.
I would like to her the devs
I would like to her the devs answer about this too. It would be sad if Tails users were left unprotected.
One US judge has a rather
One US judge has a rather unique perspective on the security flaws which Selfrando hopes to address:
http://arstechnica.com/tech-policy/2016/06/fbis-use-of-tor-exploit-is-l…
FBI’s use of Tor exploit is like peering through “broken blinds”
Judge: Making a computer reveal its IP address does not constitute a search.
Cyrus Farivar
24 Jun 2016
> Law enforcement does not need a warrant to hack someone’s computer, according to a just-unsealed court order written by a federal judge in Virginia.
> ...
> As Ars has reported before, to breach the security normally afforded by Tor, the FBI deployed a "network investigative technique" (NIT). In a related case prosecuted out of New York, an FBI search warrant affidavit described both the pornography available to Playpen’s 150,000 members and the NIT's capabilities. As a way to ensnare users, the FBI took control of Playpen and ran it for 13 days in 2015 before shutting it down. During that period, with many users’ Tor-enabled digital shields down—revealing their true IP addresses—the government was able to identify and arrest the 135 child porn suspects.
> ...
> US District Judge Henry Coke Morgan, Jr. further explained in the order on Thursday that warrantless government-sanctioned hacking "resembles" law enforcement looking through broken blinds. In this case, however, a warrant was sought and obtained. Judge Morgan found that even if the warrant did not exist—or was found to be invalid—the search would have been valid.
So should Tom wish to peer at a young girl undressing in her bedroom, that would be fine with Judge Morgan so long as Tom is peering through "broken" blinds? Broken so obscurely that the victim does not notice anything amiss?
No, judge, you are wrong about that. Wrong as wrong could be.
You want an analogy, judge? Let me suggest one: unwarranted state-sponsored rape. You now, like this incident (one of many):
> The CBP Agent became more aggressive in his questions and accusations. That CBP Agent directed Ashley to follow him to a “detention” room, ostensibly for additional questioning. Over the course of the next few hours, Ashley:
>
> a. was handcuffed to a chair;
>
> b. had a number of CBP K9’s sniff her person (a violation of CBP policy, which prohibits the use of K9’s on a person); and,
>
> c. was taken into a separate room, patted down, and asked to squat so female investigators could visually inspect her.
>
> At no point was Cervantes advised of her Miranda rights, because forget it, Jake, it's Bordertown. The CBP's inability to locate the drugs the agent fervently believed Cervantes was smuggling into the country didn't result in the conclusion of the search. Instead, efforts escalated under the theory that Cervantes was just particularly skilled in the art of concealing drugs.
>
> First, the CBP agent deployed his own questionable medical skills to fill out a "Treatment Authorization Request." In this Immigration Health Services' form, the agent "diagnosed" Cervantes as a "potential internal carrier of foreign substances" and ordered up an X-ray. Cervantes was placed in a CBP van and taken to Holy Cross Hospital, where an all-too-willing accomplice was found in the form of Dr. Patrick F. Martinez. Once there, more questionable paperwork was completed by those involved.
>
> The Holy Cross records from Ashley’s time at the facility include a number of factual inaccuracies, including inaccurately setting out that Ashley was accompanied by her mother and arrived in a private vehicle. In reality, Ashley was transported in a CBP vehicle. Her handcuffs were not removed until she changed into a hospital gown for the alleged purpose of undergoing an X-Ray.
>
> Cervantes never underwent an X-ray. Instead, she underwent a series of non-consensual penetrations -- something most people refer to as "rape."
>
> Dr. Martinez, a male physician, entered Ashley’s room and, after asking a few cursory questions, brutally invaded her body on a warrantless and unjustified search for contraband.
>
> Dr. Martinez forcefully and digitally probed Ashley’s vagina and anus.
>
> Ashley had never before been to a gynecologist and, for the remainder of her life, will always remember that her first pelvic and rectal exams were under the most inhumane circumstances imaginable to a U.S. citizen at a hospital on U.S. soil.
>
> The searches conducted by the CBP Agents, Holy Cross and Dr. Martinez injured Ashley physically, mentally and emotionally. Her labia, vaginal opening, and anus were left raw and sore and she felt violated, demeaned and powerless as a result of the searches.
>
> Seven hours. No drugs. Multiple penetrations. No warrants. No consent. And all of this will likely be OK -- or at least not enough to leap the "qualified immunity" hurdle.
>
> The courts have frequently held that the Fourth Amendment is nothing to get too concerned about near our nation's borders, what with drugs and terrorism on the loose. If the courts find it acceptable for the CBP to seize laptops and other devices and search them without a warrant, it stands to reason they'll probably find seizing and searching the lower half of a human being without probable cause to be just one of those things that happen in service of the public's "best interest."
https://motherboard.vice.com/read/court-rules-the-fbi-does-not-need-a-w…
Court Rules the FBI Does Not Need a Warrant to Hack a Computer
Joseph Cox
23 Jun 2016
> “The Court finds that no Fourth Amendment violation occurred here because the Government did not need a warrant to capture Defendant's IP address,” Henry Coke Morgan, Jr., a senior United States District Judge, wrote in an opinion and order on Tuesday. He adds that the government did not require a warrant to extract other information from the suspect’s computer either.
> ...
> According to activists, the ruling could have serious implications for how law enforcement is able to conduct remote searches... “The implications for the decision, if upheld, are staggering: law enforcement would be free to remotely search and seize information from your computer, without a warrant, without probable cause, or without any suspicion at all,” Mark Rumold, senior staff attorney at the Electronic Frontier Foundation wrote in a blog post on Thursday.
"We're the government, and we are here to rape you. Bend over. We are doing this for your own good."
https://motherboard.vice.com/read/the-fbi-is-classifying-its-tor-browse…
The FBI Is Classifying Its Tor Browser Exploit Because 'National Security'
Joseph Cox
24 Jun 2016
> Defense teams across the US have been trying to get access to a piece of malware the FBI used to hack visitors of a child pornography site. None have been successful at obtaining all of the malware's code, and the government appears to have no intention of handing it over. Now, the FBI is classifying the Tor Browser exploit for reasons of national security, despite the exploit already being used in normal criminal investigations well over a year ago. Experts say it indicates a lack of organization or technical capabilities within the FBI.
"So, you say you were raped by a federal agent? Then here's another 20 points added to your prototerrorism score. Now we need to re-examine you. Bend over."
The hardened version works
The hardened version works great! However I should also mention it eats up a lot of RAM and can easily go above 4-5 GB of RAM if you open lots of tabs. Of course people using 64bit linux often have lots of memory but still it requires some equipment.
I don't know if it works inside whonix, which I believe is 32bit.
Anyway, it works great, never crashes and looks rock stable! Thank you for your hard work!
Whonix is 64bit for the
Whonix is 64bit for the Qubes version; otherwise you're right, whonix only distributes 32bit builds. Of course, you can build it yourself...
Then again, anyone with a computer that can run Hardened Tor Browser (with the performance hit from ASan) inside a virtualizer with any reasonable amount of speed has a good chance of being able to run Qubes, and Qubes is (considered) more secure than the other VMs.
Of course, Qubes is an OS in and of itself, so it really isn't a solution for someone who doesn't want to radically change their system and isn't already running Qubes.
Currently the most readily
Currently the most readily accessible ( to non tech testers ) "system"
that is around from credible sources is the 32bit Debian8 whonix system.
Can you please wrap this in a dedicated 64bit VM appliance that will
allow folks to exercise, and compare it with the stock version?
Then it may be ued with a standard gateway VM - or a variant that
can also test the effectiveness of the latest development tor code:
packaged to permit the user to send back to you - at their consent -
"tet runs" from their own personal ISP - or selected Pubblic WiFi.
I do such things already, mostly to attempt to reverse engineer the
technicques of de-anonymity or other active interference that is
likely to be experiended by "lone wolf" targets that are otherwise
entirely law-abiding, but determined to preserve pricacy rights in
any free society within the global nework of taxpayer funded
mass surveillance.
More numbers / users and consistent testing environments make
for better statistics and reference data
Sounds great but reduces
Sounds great but reduces diversity. I think it's important that we allow users to run this hardened build on as many OS environments as possible. It would be great if installing was as easy as one two click go! The focus should be to make it easy as pie to run on any system. Always. Not just for testing.
I am a brand new Tor user.
I am a brand new Tor user. While using the Tor Browser to search using Google, Google is asking me to type in a series of characters to verify I am not a robot... I didn't do it as I would think that gives them info. Is it OK to do what they are asking??
That is basically just a
That is basically just a form of CAPTCHA, but yes, if you have JavaScript enabled for Google then they may be able to glean some information from your response.
The real answer here, though, is that you shouldn't be using Google if you care about anonymity. They have a long track record about being very aggressive in tracking people and numerous "accidental" privacy breaches.
Instead, I (and others) recommend using a privacy-respecting search engine such as DuckDuckGo, StartPage or Disconnect— one of which should have been Tor Browser's default search engine to begin with.
I would like to add that
I would like to add that Startpage displays the exact same search results as google. Aside from a few variables, you should get the same experience with the exception of how it all looks. Some people just can't stand to go without all of googles' pretty colors and presentation ;P
This is literally just an
This is literally just an advanced ASLR. Nothing to see here.
> Nothing to see here. We
> Nothing to see here.
We should always do more of whatever we are doing that causes our enemies to express concern about "losing access" in internal memos, while treating with skepticism loudly trumpeted "panic" about "going dark" (e.g. in public testimony to US Congress).
And I think it is an invaluable service to Tor users to provide some details on what TP is doing to make TBB better.
>And I think it is an
>And I think it is an invaluable service to Tor users to provide some details on what TP is doing to make TBB better.
Literally read the changelog. Holy fuck, you don't an entire blog post to tell your users what you did. What's next? Is TP going to start following Apple's footsteps and begin hosting entire conferences to tell you what they could've told you in a changelog?
> Literally read the
> Literally read the changelog. Holy fuck, you don't an entire blog post to tell your users what you did. What's next? Is TP going to start following Apple's footsteps and begin hosting entire conferences to tell you what they could've told you in a changelog?
I strongly support the Project's attempts to broaden the user base, to make tor easier for many more potentially endangered users to install and use tor with the greatest possible degree of safety. And few ordinary users are likely to get very much out of a change log, since these typically offer little to no background explanations for the layperson. That said, I'd like to see even more effort to explain even more technical matters in terms which can be understood by laypersons, preferably including those whose first language is not English. Tall order, I know.
Dude, this significantly
Dude, this significantly increases the address space and randomizes the location of each function on startup. What we see here is great leap in browser security. Couple this with disabling javascript and an attacker is going to be really pissed.
Except it's implemented
Except it's implemented entirely on the application level as opposed to mostly via the OS and requires a significantly more sophisticated implementation.
Tails should REALLY get in
Tails should REALLY get in on this ASAP.
Plus one. Selfrando,
Plus one. Selfrando, reproducible builds, and TM are three of the most promising initiatives. But there is so much else to do which is also urgently needed.
Everyone, please consider donating to TP if you are able!
"On June 27th, 2016
"On June 27th, 2016 Anonymous said:
Tails should REALLY get in on this ASAP"
The "no STATIC Entry Guards" problem is unsolved, too.
Can't be solved easily. No
Can't be solved easily. No guard has perfect uptime. Plus, if an attacker hacked your guard in this scenario, they wouldn't have to worry about you jumping to another guard. They could take their time finding your exit or HS guard to deanonymize you.
Info: "STATIC Entry
Info: "STATIC Entry Guards" is the NORMAL way tor is working.
Long term is what is meant.
Long term is what is meant. They're still temporary.
"They're still
"They're still temporary"
Yes, 3 month standard.
In Tails EntryGuards, DirectoryGuards are changing
with every booting.
That's NOT tor standard.
Exactly. The person who
Exactly. The person who replied to you is example #999999 of your average Tor user not knowing what the fuck they're talking about.
Set NumEntryGuards 3 in
Set
NumEntryGuards 3
in torrc and be happy!
More tips: set
SocksPort xxx:p0rt0
SocksPort xxx:p0rt1
switch proxy-port in browser and get new tor circuit when you need it.
btw you are not obliged to follow any standards...
Careful! Changing the number
Careful! Changing the number of your entry guards is likely a poor idea.
See
https://ocewjwkdco.tudasnich.de/blog/improving-tors-anonymity-changing-guar…
For what it's worth, it's
For what it's worth, it's running okay on Qubes-Whonix so far, although this comment box did hang on the first attempt. No errors like that reported by an earlier commentator i.e. runs straight out of the box.
The internal updater is showing tbb-nightly-hardened based on FF 45.2. Great! Although the green onion is having a fit (flashing) informing that it's not the latest update ;-) Clicking on that informs of a missing .xml file (404 error). To be expected I gather given its status.
browserprint.info shows less than 6 bits of identifying information, which is quite good (privacy slider in the highest position, no javascript). JoDoNym and other checks seem to heartily approve also.
I'll see if I can crash it running various things. I recommend that you release clear information for checking sha256sums and retrieving/checking various PGP keys & signatures if you want more testers, as the instructions above are quite confusing.
Something like this below would be good (so we don't run the three letter agency improved version by mistake):
https://sedvblmbog.tudasnich.de/docs/verifying-signatures.html.en
SMART HTTPS?
SMART HTTPS? https://addons.mozilla.org/en-US/firefox/addon/smart-https/?src=discove…
It provides opportunistic
It provides opportunistic encryption for HTTP. Not sure that feature can go to HTTPS Everywhere because just redirecting HTTP to HTTPS simply breaks too many websites. Some websites host incomplete/broken content on HTTPS. If a website needs to enable plaintext access, it should be able to announce the availability of HTTPS in a reliable way.
How is that any better than
How is that any better than HTTPS Everywhere? As far as I can tell it does the same thing and eff is relatively trustworthy.
Should we be seeing four
Should we be seeing four language packs installed in this nightly version?
Yes. We don't include all
Yes. We don't include all locales in the nightly.
Could i get abit of
Could i get abit of information and a idea of what secrets of good coding is and abit of help how to do things?
Thanks
*sigh* If only languages
*sigh*
If only languages that didn't allow bad memory access were more popular, we wouldn't need this type of stuff.
It's hard to stay motivated to learn stuff like Haskell, Rust, or whatever was used for seL4, when important projects like TorBrowser can make great advances in security by working around buffer overflow attacks by doing stuff like this.
I mean, if people are still going to use C for security, is that it? Do newer languages not allow for these issues to be fixed? Will the momentum of unsafe memory languages carry on forever? Is the sunk cost fallacy not a fallacy after all?
I know it's a question of limited resources, but why do they always fall on the same side of programming languages?
(Like, comment, subscribe to my emo livejournal, or whatever)
Agreed. The Tor project is
Agreed. The Tor project is on the cutting edge of old technology. They won't reboot until the code goes to at least 30 million lines. I think it's important for them to convince investors to enable a rewrite of the core now in rust and switch the browser to brave or servo when they (the browsers) have matured enough.
With code, less can be more. Things are way too complex in their current code base to support greater community participation. Nick has at least expressed some interest, but I fear the others might not want to step outside of their comfort zone. Even without funding this should be a top priority.
> convince
> convince investors
Wouldn't seeking investment capital require that Tor Project become a profit-making company? IMO, that would be a disaster and would cause most of the user base to leave.
Maybe I misunderstood.
So to recap, here are the
So to recap, here are the steps to obtain the hardened browser:
1. Using Tor Browser of course, surf to
https://people.torproject.org/~linus/builds/
2. Click on the lock icon to check the certificate for some evidence you really are connected to torproject.org
3. Using Tor Browser, download these public keys (short files at the given URL):
Continuous-TBB-builds-4D0DB324.asc
Continuous-TBB-builds-key.asc
4. Click on the link to descend to the directory with the nightly hardened builds:
https://people.torproject.org/~linus/builds/tbb-nightly-hardened-2016-0…
(Use the current date, not 6 Jul 2016).
5. Download these files:
sha256sums-unsigned-build.txt
sha256sums-unsigned-build.txt.asc
tor-browser-linux64-tbb-nightly-hardened_ALL.tar.xz
The first is a text file stating the SHA 256 sums of the build. The second is the detached GPG signature for that text file. The third is the tarball.
6. To verify the SHA-256 sum of the tarball, in a console, type
sha256sum tor-browser-linux64-tbb-nightly-hardened_ALL.tar.xz
Carefully check that the reported hash matches exactly the string given in the file named sha256sums-unsigned-build.txt
7. To verify the authenticity of the reported hash value, in a console, type
gpg --import Continuous-TBB-builds-key.asc
gpg --verify sha256sums-unsigned-build.txt.asc sha256sums-unsigned-build.txt
The first command imports the needed key into your keyring. The second verifies the detached signature sha256sums-unsigned-build.txt.asc. If all is good, you should see something like this:
gpg: Signature made Wed 06 Jul 2016 06:21:05 UTC
gpg: using RSA key 0xD1982B344D0DB324
gpg: Good signature from "Continuous TBB builds" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B06F C0C1 F35B 8462 A2DB 64DA D198 2B34 4D0D B324
7. But we still don't know that this key really belongs to Linus N, so check the key itself using
gpg --edit-key 0xD1982B344D0DB324
> check
You should see that the key is self-signed, which doesn't help. If you already have a second key owned by Linus N you should also see
sig! 0x1E8BF34923291265 2015-10-20 Linus Nordberg
If not, go to a key server and search for and then import into your keyring the key 0x1E8BF34923291265
Try "check" again and you should see GPG confirming that Linus signed the special key used only to sign the TBB hardened nighly builds. You can check his key to see that it is indeed signed by many Tor Project employees and other people, at least one of whom you hopefully trust.
8. At this point you are probably safe to unpack the tarball in an appropriate directory in your Linux system 64-bit test machine havng at least 3 GB of RAM.
(Since I don't have one of those yet, I must report back with my experience of what actually happens when I try following step 8.)
If I got anything wrong, please correct the mistake!
Another frightening
Another frightening development which shows why we all need to get cracking and test Selfrando, because the changes to Rule 41 come into effect on 1 Dec, which will allow FBI agents (without any hint of effective oversight by any other entity) to attack any computer anywhere in the world at any time for any reason:
https://freedom.press/blog/2016/06/leaked-fbi-documents-reveal-secret-r…
Leaked FBI documents reveal secret rules for spying on journalists with National Security Letters
Trevor Timm
30 Jun 2016
> Today, The Intercept published leaked documents that contain the FBI’s secret rules for targeting journalists and sources with National Security Letters (NSLs)—the controversial and unconstitutional warrantless tool the FBI uses to conduct surveillance without any court supervision whatsoever.
> ...
> First, the rules clearly indicate—in two separate places—that NSLs can specifically be used to conduct surveillance on reporters and sources in leak investigations. This is quite disturbing, since the Justice Department spent two years trying to convince the public that it updated its “Media Guidelines” to create a very high and restrictive bar for when and how they could spy on journalists using regular subpoenas and court orders. These leaked rules prove that the FBI and DOJ can completely circumvent the Media Guidelines and just use an NSL in total secrecy.
https://www.techdirt.com
Senate Funding Bill For State Dept. Asks It To Figure Out Ways To Stop Bad People From Using Tor
Mike Masnick
6 Jul 2016
> It would appear that Congress is not so happy that the State Department is a major funding source for the Tor project. Tor, of course, is the internet anonymyzing system that was originally developed with support from the US government as a way to promote free and safe access to the internet for people around the globe (mostly focusing on those under threat in authoritarian countries). Of course, other parts of our government aren't huge fans of Tor, because it doesn't just help activists and dissidents in other countries avoid detection, but also, well, just about anyone (except on days when the FBI decides to hack their way in).
>
> There has, of course, always been some tension there. There are always the conspiracy theorists who believe that because Tor receives US government funding it is by default compromised. Those tend to be tinfoil hat wearing types, though.
I tended to think that too, until I heard about David Chasteen. And to my dismay, neither Shari, nor Roger, nor Karen have said so much as one single word in public about the disgraceful episode in which Tor Project hired a CIA agent (and it *is* a bit hard to believe that Roger really had no clue) to write code.
(For those who haven't been reading the leaked files at Cryptome, this happened before Shari came on board. Chasteen was fired after Jacob Appelbaum started asking about his background, at which point Chasteen admitted to Roger he had only formally quit CIA the day before joining Tor Project. Oh my. And USIC is like the mafia: you can't really quit, although sometimes you pretend to quit. Still, there are many questions which need to be answered, and Karen, Roger, and Shari are the only ones who can answer them. And the answer better not be "we can't violate our out of court settlement" or "we can't violate the terms of our contract with Sponser X", or some such nonsense which will hardly quiet the concerns of many Tor users who have good reason not to view CIA as a bunch of kindly, well-intentioned, highly professional and extremely ethical people who never exhibit bad judgment and who never commit crimes anywhere in the world.)
> The folks who work on Tor are not exactly recognized for being particularly friendly to intrusive government surveillance. They tend to be the exact opposite of that. And, of course, part of the Snowden revelations revealed that Tor was one tool that still stymied the NSA in most cases.
>
> But it appears that Congress may be quietly trying to undermine this. On Friday, Politico had a tiny blurb in passing about how the latest State Department appropriations bill making its way through Congress includes some references to stopping "circumvention technologies" from being used by bad people. The Politico report suggests this is designed to apply more broadly to encryption, but reading the specifics it appears to be targeted straight at Tor. Here's the Senate report on the appropriations, where it discusses funding related to "internet freedom."
I think Masnick is probably correct about the intent of the people who wrote this bit into the bill. (Not the sponsors, not their staff, but the people who wrote that part of the bill: the lawyers who work for the spooks. Ugly.)
Running the 7-6 nightly
Running the 7-6 nightly hardened here and its doing fine. fyi, its in a vm on a debian host. All 64 bit linux.
Defending against code-reuse
Defending against code-reuse attacks is one of the hardest problems in history. I'm actually pretty surprised Tor Project is jumping into this, when it's so obviously not going to be effective. I could get into a list of trivial ways it could be bypassed. Right now I'll just post a log from #grsecurity on OFTC when I asked spender (the grsecurity dev) about this. He's one of the people, along with pipacs who is extremely familiar with code-reuse attacks, and has one of the only actually working defense mechanisms (RAP):
01:35 < ryona> spender: what do you think of the new firefox (well, tor browser) "selfrando" thing? https://people.torproject.org/~gk/misc/Selfrando-Tor-Browser.pdf
01:35 < ryona> it claims to randomize the internal structure of the browser to defend against code reuse attacks
01:36 < spender> it claims a lot
01:36 < spender> :p
01:36 < ryona> when i skimmed through the paper, the only thing i could think was "holy fuck this looks so useless"
01:36 < spender> you'd be right
01:36 < spender> we discussed it here already a few weeks ago :p
I know it sounds harsh, but this is, effectively, completely useless for something like a browser. If this were being sold, it should be considered fraud. Because it's free, it's just yet another an academic paper which tries to attack the nearly impossible problem of code-reuse attacks which is being taken too seriously.
> I could get into a list of
> I could get into a list of trivial ways it could be bypassed.
Details, please?
Can't you add more security
Can't you add more security feature to Tor, like:
Stricter sandboxing, prevent leakage of mac addresses, host names and direct network connection after an exploit.
Realtime intrusion detection, automatic real IP-address leakage detection and a Tor friendly version of the
OWASP ModSecurity Core Rule Set for Tor Hidden Services.
"Stricter sandboxing" -
"Stricter sandboxing" - Firefox developers are working on this and are getting very close to being finished for all main OS variants.
"Prevent leakag of mac addresses, host names and direct network connection after an exploit" - Run Tor (Selfrando version) in Whonix which protects against MAC address identification. Better yet, run it in Qubes-Whonix so you get IOMMU protection re: the network stack.
Assume in advance that the feds (and every other totalitarian regime) are attacking everyone already without waiting for Rule 41 changes. Thus, it would be stupid to run Tor on top of a buggy monolithic kernel, be it Windows, Mac OS or Linux, since you are one exploit away from being identified.
Anyone at serious risk should be using TAILS only from random computers.
Best practice is to use a hypervisor (Xen) with strict isolation and slimmed down, hardened Whonix appVM templates. Then, if the feds want to hack your system and de-anonymize you they must:
a) exploit the Tor Browser with a zero day
b) try and escape the appVM with a Xen exploit to attack dom0
c) waste lots of time and resources instead of getting easy de-anonymization with passive attack tools
If you really care about this issue deeply, contribute funds to Tor, Whonix and Qubes developers. Contribute your expertise if you can. Encourage everybody your know to use Tor and help them to get started if they need it.
While using hardened TB
While using hardened TB (security settings High, otherwise default), noticed SSDP (yes?) on 64 bit Debian 8.5 test machine sending a few packets from local address 239.255.255.250 (yes?) to my router, a device which I don't trust not to mess up. Could this be a problem? I wasn't trying to print or anything which I guess could trigger legitimate SSDP traffic on the LAN, and have no externals attached (other than the router).
Immediately after the above
Immediately after the above was submitted (before it appeared), this behavior ceased. Was it caused by a malfunction of the metrics data gathering system? A misconfiguration at my end? Chinese (Russian, American, French, Israeli) intelligence?
Comments from Tor staff, please?
check: downloaded and
check: downloaded and verified the tarball.
check: unpacked in 64-bit test machine (with about 6GB of memory).
check: hardened Tor Browser starts from the provided script.
check: spotchecked ability to browse the web using Tor.
check: can post to this blog.
Just one possible minor bug noticed so far: on 15 Jul 2016 I have the nightly build dated 12 Jul 2016 which as far as I can tell is the most recent, but Tor Browser warns that I am using an outdated version. Also the updater doesn't appear to work but that is presumably expected for the hardened browser nighly build?
Using hardened browser on 64
Using hardened browser on 64 bit test machine. Can
o start Tor Browser
o surf the open Internet
o see the circuits (results agree with check.torproject.org)
o change identities (confirmed by check.torproject.org)
and in general do everything normally.
I think I see some memory usage, but if you are using a machine with 4 or more GB of RAM I don't think memory should be a problem, unless perhaps if you keep many tabs open when you surf, instead of frequently chosing "New identity".
Do keep up the good work!
A few more observations: o
A few more observations:
o hardened browser can easily eat up 2GB of RAM when visting sites which try to make browser open many adware type connections,
o choosing "new identity" does *not* immediately cut off incoming streams of data from a site you are trying to leave, but closing the browser entirely, then restarting from the provided script seems to fix that--- but is this a safe practice?