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.

Except it's implemented entirely on the application level as opposed to mostly via the OS and requires a significantly more sophisticated implementation.

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!

Anonymous

June 28, 2016

Permalink

"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 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.

"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 replied to you is example #999999 of your average Tor user not knowing what the fuck they're talking about.

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...

Anonymous

June 29, 2016

Permalink

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://www.torproject.org/docs/verifying-signatures.html.en

Anonymous

July 02, 2016

In reply to by Anonymous (not verified)

Permalink

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.

Anonymous

July 02, 2016

In reply to by Anonymous (not verified)

Permalink

How is that any better than HTTPS Everywhere? As far as I can tell it does the same thing and eff is relatively trustworthy.

Anonymous

June 30, 2016

Permalink

Should we be seeing four language packs installed in this nightly version?

Anonymous

July 03, 2016

Permalink

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

Anonymous

July 06, 2016

Permalink

*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 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 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.

Anonymous

July 06, 2016

Permalink

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!

Anonymous

July 06, 2016

Permalink

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.)

Anonymous

July 08, 2016

Permalink

Running the 7-6 nightly hardened here and its doing fine. fyi, its in a vm on a debian host. All 64 bit linux.

Anonymous

July 11, 2016

Permalink

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.

Anonymous

July 13, 2016

Permalink

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" - 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 (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 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?

Anonymous

July 14, 2016

Permalink

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?

Anonymous

July 14, 2016

Permalink

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!

Anonymous

July 14, 2016

Permalink

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?