The Tor Social Contract

At The Tor Project, we make tools that help promote and protect the essential human rights of people everywhere. We have a set of guiding principles that make that possible, but for a long time, those principles were more or less unspoken. In order to ensure that project members build a Tor that reflects the commitment to our ideals, we've taken a cue from our friends at Debian and written the Tor Social Contract -- the set of principles that show who we are and why we make Tor.

Our social contract is a set of behaviors and goals: not just the promised results we want for our community, but the ways we seek to achieve them. We want to grow Tor by supporting and advancing these guidelines in the time we are working on Tor, while taking care not to undermine them in the rest of our time.

The principles can also be used to help recognize when people's actions or intents are hurting Tor. Some of these principles are established norms; things we've been doing every day for a long time; while others are more aspirational -- but all of them are values we want to live in public, and we hope they will make our future choices easier and more open. This social contract is one of several documents that define our community standards, so if you're looking for things that aren't here (e.g. something that might be in a code of conduct) bear in mind that they might exist, in a different document.

Social goals can be complex. If there is ever tension in the application of the following principles, we will always strive to place highest priority on the safety and freedom of any who would use the fruits of our endeavors. The social contract can also help us work through such tensions -- for example, there are times when we might have a need to use tools that are not completely open (contradicting point 2) but opening them would undermine our users' safety (contradicting point 6). Using such a tool should be weighed against how much it's needed to make our technologies usable (point 1). And if we do use such a tool, we must be honest about its capabilities and limits (point 5).

Tor is not just software, but a labor of love produced by an international community of people devoted to human rights. This social contract is a promise from our internal community to the rest of the world, affirming our commitment to our beliefs. We are excited to present it to you.

1. We advance human rights by creating and deploying usable anonymity and privacy technologies.

We believe that privacy, the free exchange of ideas, and access to information are essential to free societies. Through our community standards and the code we write, we provide tools that help all people protect and advance these rights.

2. Open and transparent research and tools are key to our success.

We are committed to transparency; therefore, everything we release is open and our development happens in the open. Whenever feasible, we will continue to make our source code, binaries, and claims about them open to independent verification. In the extremely rare cases where open development would undermine the security of our users, we will be especially vigilant in our peer review by project members.

3. Our tools are free to access, use, adapt, and distribute.

The more diverse our users, the less is implied about any person by simply being a Tor user. This diversity is a fundamental goal and we aim to create tools and services anyone can access and use. Someone's ability to pay for these tools or services should not be a determining factor in their ability to access and use them. Moreover, we do not restrict access to our tools unless access is superceded by our intent to make users more secure.

We expect the code and research we publish will be reviewed and improved by many different people, and that is only possible if everyone has the ability to use, copy, modify, and redistribute this information. We also design, build, and deploy our tools without collecting identifiable information about our users.

4. We make Tor and related technologies ubiquitous through advocacy and education.

We are not just people who build software, but ambassadors for online freedom. We want everybody in the world to understand that their human rights -- particularly their rights to free speech, freedom to access information, and privacy -- can be preserved when they use the Internet. We teach people how and why to use Tor and we are always working to make our tools both more secure and more usable, which is why we use our own tools and listen to user feedback. Our vision of a more free society will not be accomplished simply behind a computer screen, and so in addition to writing good code, we also prioritize community outreach and advocacy.

5. We are honest about the capabilities and limits of Tor and related technologies.

We never intentionally mislead our users nor misrepresent the capabilities of the tools, nor the potential risks associated with using them. Every user should be free to make an informed decision about whether they should use a particular tool and how they should use it. We are responsible for accurately reporting the state of our software, and we work diligently to keep our community informed through our various communication channels.

6. We will never intentionally harm our users.

We take seriously the trust our users have placed in us. Not only will we always do our best to write good code, but it is imperative that we resist any pressure from adversaries who want to harm our users. We will never implement front doors or back doors into our projects. In our commitment to transparency, we are honest when we make errors, and we communicate with our users about our plans to improve.

Same here. Message "Your Firefox is out of date. Please download a fresh copy." On Tor Browser 6.0.3. But it is the latest version, so I assume it is a bug.

Anonymous

August 11, 2016

Permalink

I believe point 2 could, and should, be worded more strongly towards software freedom.

First it states:

"[...] everything we release is open [...]"

next:

"Whenever feasible, we will continue to make our source code [...] open to independent verification."

Saying "Whenever feasible" with regards to open independent verification implies that it might not always be possible to do so. If an independent entity cannot verify the source code, it is not open. Thus contradicting the first statement.

Yes, this is a very strange thing to say! Can anyone from Tor provide an example of a circumstance where it would not be feasible to make some source code open?

Tor and group of volunteers run software that actively monitor the network to find malicious nodes (e.g. exit nodes mangling traffic or harvesting onion services). Releasing their source code would offer an easy way for attackers to avoid detection. This would most likely harm our users (contradicting point 6).

We added the “whenever feasible” so no one would accuse us of keeping these monitoring software to ourselves when it's currently the most sensible thing to do. Hope that explains.

It's indeed suboptimal. In the meantime, making such a tradeoff allows to catch malicious relays which tries to spy on Tor users.

If you take the example of relays harvesting onion services, this is a problem that will be solved for good after the implementation and deployment of the new design (prop224). In some cases, these are also tradeoffs that helps to make the situation slightly better while more general solutions are in the making.

"Catch malicious relays which tries to spy on Tor users":

In the weeks before the latest batch of suspicious relays was removed, while using Tails on a laptop, I noticed anomalies which seemed to be related to what turned out to be a vulnerability which could affect onion services.

More recently when using Tails to connect to a bridge (my ISP seems to block Tor using some kind of crude censorship) I have repeatedly noticed in Onion Circuits a specific line which appears to correspond to an entry node (with a nickname consisting of many zeros but with no IP address or other information), but which never completes any circuits. Any idea what that might be? According to blutmagie, there is a node with a nickname consisting of all zeros but that seems to be different from what I am seeing.

Tails, not regular Tor Browser, but Tails is an allied project, so TP should probably help Tails users understand worrisome observations, yes?

Has anyone else connecting to slate.com and salon.com while using Tor Browser (or the TB version in current Tails) noticed a change in behavior in recent weeks? One seems to have downgraded its https which results in TB failing to establish an encrypted connection from the exit node.

This is the definition of security through obscurity. It would not be difficult for someone to obtain the source of that software. I would not be surprised if it is already in the hands of our adversaries. Meanwhile, they and only they have it and can abuse it, while the greater Tor community cannot read it to improve upon it due to the secretive nature.

I've contributed to the Tor community and am a regular on the IRC channels. I don't believe it would be particularly hard for me to get my hands on that software, as a volunteer. If I were malicious, I could very easily provide that source to someone who would use it for evil. I have been thinking of working to that position, although I have no plans to do something evil of course! But the fact that it's possible only because of the closed-source nature is not good.

If you can come up with methods that can be 100% public on how bad exits or onion harvesting nodes can be deteted in a way that can't be defected by our adversaries, that would be plain awesome. So far, I don't think anyone has invented one.

Again, the undisclosed TP authored source code we are talking about appears to refer to something like scripts running on special purpose nonpublic servers which attempt to catch out malicious relays, which will obviously help improve the security of the Tor network and thus of endangered Tor users.

I think the key point has already been mentioned: the TP response to the problem is less than ideal, but it appears that no one can suggest anything which is truly better.

> This is the definition of security through obscurity. It would not be difficult for someone to obtain the source of that software. I would not be surprised if it is already in the hands of our adversaries.

You raise a very topical point. No less a figure than Edward Snowden believes that the likely source of the leaked Equation Group (NSA) source code, which contains hundreds of zero-days used to attack Cisco and other brand name top of the line routers, is a cyberespionage C&C server or data-exfiltration node (see tweets below).

Some Tor users have suggested that TP set up carefully constructed honeypot onion services on geographically distributed servers, and share with CitizenLabs, to try to get a sense of who is attacking onion services and more importantly, how they are doing that. We pointed out that this is not without risk because such servers are likely not under 24/7 TP physical control, which poses a risk. We pointed out that NSA faces the same problem with its geographically distributed data-exfiltration cyberespionage servers, which are often not under 24/7 USG physical control.

And some Tor users have urged TP to ally with EFF, ACLU, etc., and to reach out to US politicians and the better-informed tech reporters to counter the many false claims from bad actors such as FBI about the dangers of mandatory backdoors. USIC allies always claim NOBUS (nobody but US) knows about the zero-day exploits which NSA intends to never divulge, but this claim has been *decisively* debunked by the leak of Equation Group source code, which shows that non-NSA actors have have Equation Group source code since Jun 2013, if not before:

https://www.washingtonpost.com
Powerful NSA hacking tools have been revealed online
Ellen Nakashima
16 Aug 2016

> Some of the most powerful espionage tools created by the National Security Agency’s elite group of hackers have been revealed in recent days, a development that could pose severe consequences for the spy agency’s operations and the security of government and corporate computers. A cache of hacking tools with code names such as Epicbanana, Buzzdirection and Egregiousblunder appeared mysteriously online over the weekend, setting the security world abuzz with speculation over whether the material was legitimate.
>
> The file appeared to be real, according to former NSA personnel who worked in the agency’s hacking division, known as Tailored Access Operations (TAO). “Without a doubt, they’re the keys to the kingdom,” said one former TAO employee, who spoke on the condition of anonymity to discuss sensitive internal operations. “The stuff you’re talking about would undermine the security of a lot of major government and corporate networks both here and abroad.” Said a second former TAO hacker who saw the file: “From what I saw, there was no doubt in my mind that it was legitimate.”
>
> The file contained 300 megabytes of information, including several “exploits,” or tools for taking control of firewalls in order to control a network, and a number of implants that might, for instance, exfiltrate or modify information.
> ...
> Several of the exploits were pieces of computer code that took advantage of “zero-day” or previously unknown flaws or vulnerabilities in firewalls, which appear to be unfixed to this day, said one of the former hackers. The disclosure of the file means that at least one other party — possibly another country’s spy agency — has had access to the same hacking tools used by the NSA and could deploy them against organizations that are using vulnerable routers and firewalls. It might also see what the NSA is targeting and spying on. And now that the tools are public, as long as the flaws remain unpatched, other hackers can take advantage of them, too.
> ...
> Critics of the NSA have suspected that the agency, when it discovers a software vulnerability, frequently does not disclose it, thereby putting at risk the cybersecurity of anyone using that product. The file disclosure shows why it’s important to tell software-makers when flaws are detected, rather than keeping them secret, one of the former agency employees said, because now the information is public, available for anyone to employ to hack widely used Internet infrastructure.

https://www.techdirt.com
Ed Snowden Explains Why Hackers Published NSA's Hacking Tools
Mike Masnick
16 Aug 2016

> Yesterday, the news broke that a "mysterious" hacking group had gotten its hands on some NSA hacking tools and was releasing some of the tools as proof (it was also demanding lots of Bitcoin to reveal more). The leak came with a neat little message that feels like it was written by a Hollywood script writer trying to sound Russian.... The files that were leaked [so far] were mostly installation scripts, but also exploits designed for specific routers and firewalls. And, it's noted, that some of the tools named line up with previously leaked NSA codenames.

http://arstechnica.com/security/2016/08/code-dumped-online-came-from-om… hacking tool leak came from “omnipotent” NSA-tied group
Rare crypto implementation in ShadowBrokers dump connects it to Equation Group.
Dan Goodin
16 Aug 2016

> The connection linking more than 300 computer files in the ShadowBrokers archive to Equation Group is found in a common implementation of the RC5 and RC6 encryption algorithms. Among other things, the leaked ShadowBroker files use the negative constant -0x61C88647 instead of the more standard 0x61C88647 to speed up subtraction operations. Kaspersky researchers scoured 20 different compiled versions of RC5/6 code in Equation Group malware and found functionally identical code, leaving little doubt that there was a clear connection between the two.

http://thehill.com/policy/cybersecurity/291470-hackers-claim-auction-of…
Hackers claim to auction NSA source code
Joe Uchill
15 Aug 2016

> Hackers calling themselves Shadow Brokers are auctioning off what they claim is the source code to a vaunted, likely state-sponsored hacking group many believe is affiliated with the National Security Agency. There is no definitive proof the auction is genuine, but files released to prove authenticity appear valid enough to have piqued the interest of many in the security community.
>
> The cybersecurity firm Kaspersky Labs raised eyebrows last year with a report on a hacking operation it was calling the Equation Group, which had managed to operate without being noticed for 14 years. That is an uncommonly long time for a state group to stay under the radar given the resources they are normally up against. Kaspersky noted similarities from Equation to attack methods discussed in leaked NSA documents and other suspected U.S. intelligence malware. The computer code used jargon common to the NSA and time codes in the Equation Group’s wares appeared to match a North or South American workday.
> ...
> “The code in the dump seems legitimate, especially the Cisco exploits (Most of the dump contains Firewall exploits), and those exploits were not public before,” said Matt Suiche, via electronic chat. Suiche is the founder of United Arab Emirates-based cybersecurity start-up Comae Technologies and has been actively analyzing the source code portions released as proof. Particularly interesting, said Suiche, are references to code names listed in the NSA Advanced Network Technology Catalogue, a listing of the agencies cyber warfare capabilities.

http://thehill.com/policy/cybersecurity/291565-wikileaks-too-claims-to-…
WikiLeaks, too, claims to have NSA code
Joe Uchill
16 Aug 2016

> After a day of speculation over whether the previously unknown “Shadow Brokers” could really be auctioning off an authentic stolen copy of the vaunted espionage group’s source code, WikiLeaks announced it would be releasing a free, “pristine” copy.

http://thehill.com/policy/cybersecurity/291588-snowden-suggests-russia-…
Snowden suggests Russia behind NSA code hack
Joe Uchill
16 Aug 2016

> National Security Agency (NSA) leaker Edward Snowden is backing a theory that Russia — not money-seeking hackers — is behind the release of possible NSA source code.

Snowden tweeted the following in a multi-tweet statement:

> The hack of an NSA malware staging server is not unprecedented, but the publication of the take is. Here's what you need to know:
> 1) NSA traces and targets malware C2 servers in a practice called Counter Computer Network Exploitation, or CCNE. So do our rivals.
> 2) NSA is often lurking undetected for years on the C2 and ORBs (proxy hops) of state hackers. This is how we follow their operations.
> 3) This is how we steal their rivals' hacking tools and reverse-engineer them to create "fingerprints" to help us detect them in the future.
> 4) Here's where it gets interesting: the NSA is not made of magic. Our rivals do the same thing to us -- and occasionally succeed.
> 5) Knowing this, NSA's hackers (TAO) are told not to leave their hack tools ("binaries") on the server after an op. But people get lazy.
> 6) What's new? NSA malware staging servers getting hacked by a rival is not new. A rival publicly demonstrating they have done so is.
> 7) Why did they do it? No one knows, but I suspect this is more diplomacy than intelligence, related to the escalation around the DNC hack.
> 8) Circumstantial evidence and conventional wisdom indicates Russian responsibility. Here's why that is significant:
> 9) This leak is likely a warning that someone can prove US responsibility for any attacks that originated from this malware server.
> 10) That could have significant foreign policy consequences. Particularly if any of those operations targeted US allies.
> 11) Particularly if any of those operations targeted elections.
> 12) Accordingly, this may be an effort to influence the calculus of decision-makers wondering how sharply to respond to the DNC hacks.
> 13) TL;DR: This leak looks like a somebody sending a message that an escalation in the attribution game could get messy fast.
> Bonus: When I came forward, NSA would have migrated offensive operations to new servers as a precaution - it's cheap and easy. So? So...
> The undetected hacker squatting on this NSA server lost access in June 2013. Rare public data point on the positive results of the leak.

(I think his point is that after Snowden's first leaks in Jun 2013, NSA did a huge internal audit which may have caught the intrusion, or scared off the intruders.)

I don't think anyone here ever doubted that NSA is the author of most of the Equation Group exploits, which were previously linked to the ANT catalog, but immediately after the source code was leaked, nsa.gov went offline for about 18 hours, suggesting the agency is conducting an emergency audit similar to what happened just after the first Snowden leaks.

There is really no doubt that the leaks include many zero-day exploits which NSA long claimed nobody but them would ever know about. We said that was absurd, and these leaks prove that we are right.

I urge Shari give top priority in next few months to the political fight to persuade US Congress to act in time to block the change to Rule 41 which will authorize FBI to "legally" (under US law) attack any computer anywhere in the world, anytime, for any reason, under a PRISM style blanket warrant (or maybe, none at all, because no-one will be checking to see that FBI agents follow the broadly written but unenforced rules).

"Again, the undisclosed TP authored source code we are talking about appears to refer to something like scripts running on special purpose nonpublic servers which attempt to catch out malicious relays, which will obviously help improve the security of the Tor network and thus of endangered Tor users."

Oh wait, maybe not, no... Lunar wrote:

"Tor and group of volunteers run software that actively monitor the network to find malicious nodes (e.g. exit nodes mangling traffic or harvesting onion services)." (Bold emphasis mine.)

I can't quickly find something exactly on that topic, but I can point out a recent paper at PETS 2016 where, as Ross Anderson reports, "Amirali Sanatinia has been working on hidden service directories, and the problem that some can be malicious." (https://www.lightbluetouchpaper.org/2016/07/19/pets-2016/).

Now, what's going on here is that PET and security researchers are say writing their own tools or even putting together particular hardware/software test harnesses to analyse what they see on the Tor network. These, software included, are nothing to do with the Tor software itself, and so aren't and don't need to be covered by the Tor Social Contract.

How can I put this? Google searches the internet. One might use it to locate sites with, say, Tor source code or binaries to download. Google might list several sites - some real, some fake. That's an interesting discovery by using Google. What if Tor Project wrote a script to use Google to regularly search for fake downloads of Tor?

Obviously, you can't demand Google release its search engine source code just because the Tor Social Contract says it's open about Tor source code, and Google might not want to reveal exactly how it ranks websites in case someone uses that knowledge to manipulate search result rankings.

Now, that script isn't part of the actual Tor software, so do you think the Social Contract demands the Tor Project must publish the script? I would say "no."

Does this clarify things?

If Tor Project is automating a Google search, they are not running closed source software unless the automation software is closed source. You would not say that they are running closed source software anymore than you would say I am running closed source software right now, just because this comment is likely going to be routed through some closed-source Cisco router running IOS or some Juniper.

"(I think his point is that after Snowden's first leaks in Jun 2013, NSA did a huge internal audit which may have caught the intrusion, or scared off the intruders.)"

"... immediately after the source code was leaked, nsa.gov went offline for about 18 hours, suggesting the agency is conducting an emergency audit similar to what happened just after the first Snowden leaks."

I think what Edward Snowden meant was that the NSA 'burned' any systems he had worked on after he whistleblew in 2013, and they probably 'burned' whatever they had recently too. Yet, not literally burned, just as in "Burn Notice" - you get dropped. I imagine there are huge stashes of hardware in 'quarantine' now, any audit unlikely to happen due to the sheer scale if it. I doubt there'll be a yard sale either, so no cheap exit node hardware for us!

I expect this scenario will get worked into a future episode of NCIS, where Abby Sciuto and Timothy McGee have to locate some piece of code on some server in a storage basement like out of "Raiders of the Lost Ark", and they'll do it in a ridiculously short time. Because cyber.

> I think what Edward Snowden meant was that the NSA 'burned' any systems he had worked on after he whistleblew in 2013

No, they continued using most of the secret deals, secret arrangements (e.g. with Verizon), secret dragnet espionage systems, NOBUS [sic] zero day exploits, etc, but changed some codenames.

Snowden tweeted

> "The undetected hacker squatting on this NSA server lost access in June 2013. Rare public data point on the positive results of the leak."
> ...
> "The NSA is not made of magic. [Other actors attack NSA with the same methods used by NSA] -- and occasionally succeed."

I think what he meant was that after the first leaks in Jun 2013, NSA performed a huge audit (this much is a known fact, not speculation) which may have uncovered (here begins informed speculation):

(i) an intrusion into a rented covert server "hiding in plain sight" in some commercial data center or IX, secretly operated by NSA, which had been used by NSA to serve malware to "downstream", to the other data center customers, to ISPs, etc.,

(ii) the fact that an NSA/TAO operative had mistakenly uploaded a huge amount of Equation Group code to this compromised covert server.

I can't see NSA shutting down *all* its covert servers in Jun 2013, if that is what you meant to suggest, because that would have left the agency unable to continue to try to "Collect it All". NSA has consistently preferred to continue collections even in cases where it knows other actors are watching them spy.

I guess we'll have to see whether Snowden explains further.

Researchers have only just begun to analyze the vast trove of NSA Equation Group malware published by Wikileaks, even as USIC frantically tries to "spin" this story to make them look less awful.

USIC sources were quick to assure "friendly" US reporters that the leaked exploits are old (2013 or earlier) and no longer work, and required unlikely sounding prerequisites, such as attacking from inside the LAN (i.e. not attacking a firewall's outward facing interface). But evidence is already emerging which casts doubt on these self-serving reassurrances:

https://motherboard.vice.com/read/researcher-grabs-cisco-vpn-password-w…
Researcher Grabs VPN Password With Tool From NSA Dump
Joseph Cox
19 Aug 2016

> Security researcher Mustafa Al-Bassam first documented the hacking tool, which uses the codename BENIGNCERTAIN, in a blog post published Thursday. He coined the attack “PixPocket” after the hardware the tool targets: Cisco PIX, a popular, albeit now outdated, firewall and VPN appliance. Corporations or government departments might use these devices to allow only authorised users onto their network. Based on his analysis of the code, Al-Bassam writes that the tool works by sending a packet to the target machine that makes it dump some of its memory. Included in that dump is the VPN’s authentication password, which is used to log into the device.

Snowden was quick to point out that the Equation Group malware scripts were probably obtained when someone in NSA/TAO goofed and uploaded a large number of NSA malwares to a "staging server" not under NSA's physical control.

Let me try to explain: USIC operatives use fake identities to hire server space in commercial data centers all over the world, where NSA can more easily attack other entities who use the same data centers, but where they can more easily be attacked themselves. Similarly, NSA sneaks covert malware servers into IXs worldwide. Further, various documents in the Snowden leaks published so far show that TAO operatives have not infrequently made the kind of mistake Snowden was talking.

But an anonymous NSA person suggested that the source might be a new inside leaker:

https://motherboard.vice.com/read/former-nsa-staffers-rogue-insider-sha…
Former NSA Staffers: Rogue Insider Could Be Behind NSA Data Dump
Lorenzo Franceschi-Bicchierai and Joseph Cox
17 Aug 2016

> There are a lot of unanswered questions surrounding the shocking dump of a slew of hacking tools used by an NSA-linked group earlier this week. But perhaps the biggest one is: who’s behind the leak? Who is behind the mysterious moniker “The Shadow Brokers”?
> ...
> An insider could have stolen them directly from the NSA, in a similar fashion to how former NSA contractor Edward Snowden stole an untold number of the spy agency’s top secret documents. And this theory is being pushed by someone who claims to be, himself, a former NSA insider. “My colleagues and I are fairly certain that this was no hack, or group for that matter,” the former NSA employee told Motherboard. “This ‘Shadow Brokers’ character is one guy, an insider employee.”

We do know that there are persons working inside NSA who are deeply worried about what NSA is doing, as Snowden was, but I think Snowden's guess about how the Equation Group source code was leaked will prove correct.

> Snowden was quick to point out that the Equation Group malware scripts were probably obtained when someone in NSA/TAO goofed and uploaded a large number of NSA malwares to a "staging server" not under NSA's physical control.
> ...
> I think Snowden's guess about how the Equation Group source code was leaked will prove correct.

Reuters is now reporting that Snowden was indeed correct:

http://www.theregister.co.uk/2016/09/23/report_nsa_covered_up_zeroday_l…
Report: NSA hushed up zero-day spyware tool losses for three years
Investigation shows staffer screw-up over leak
Iain Thomson
23 Sep 2016

> Sources close to the investigation into how NSA surveillance tools and zero-day exploits ended up in the hands of hackers has found that the agency knew about the loss for three years but didn’t want anyone to know. Multiple sources told Reuters last night that the investigation into the data dump released by a group calling itself the Shadow Brokers had determined that the NSA itself wasn't directly hacked and the software didn't come from exiled whistleblower Edward Snowden. Instead it appears one of the NSA staffers got sloppy.
>
> It appears at this stage that the staffer, who has since left the NSA for other reasons, stashed the sensitive tools on an outside server – likely a bounce box – after an operation. Miscreants then found that machine, raided it and hit the jackpot. The staffer informed his bosses after the incident, but rather than warning companies like Cisco that their customers were at risk, the NSA kept quiet. The reasoning for this secrecy seems to have been that the NSA wanted to see who was going to use them. It monitored the world's internet traffic to try and catch sight of the tools or someone using the software or the holes it exploited. Since no signs appeared the agency didn’t tell anyone of the loss.

The staffer may be the former NSA/TAO employee who now is a network security analyst for Comcast. Just the sort of person who should be trusted with the personal information of tens of millions of Americans.

https://theintercept.com/2016/08/19/the-nsa-was-hacked-snowden-document…
The NSA Leak Is Real, Snowden Documents Confirm
Sam Biddle
19 Aug 2016

> On Monday, a hacking group calling itself the “ShadowBrokers” announced an auction for what it claimed were “cyber weapons” made by the NSA. Based on never-before-published documents provided by the whistleblower Edward Snowden, The Intercept can confirm that the arsenal contains authentic NSA software, part of a powerful constellation of tools used to covertly infect computers worldwide.
>
> The provenance of the code has been a matter of heated debate this week among cybersecurity experts, and while it remains unclear how the software leaked, one thing is now beyond speculation: The malware is covered with the NSA’s virtual fingerprints and clearly originates from the agency.
>
> The evidence that ties the ShadowBrokers dump to the NSA comes in an agency manual for implanting malware, classified top secret, provided by Snowden, and not previously available to the public. The draft manual instructs NSA operators to track their use of one malware program using a specific 16-character string, “ace02468bdf13579.” That exact same string appears throughout the ShadowBrokers leak in code associated with the same program, SECONDDATE.
> ....

Hmm, no I think the poster referring to "Security thru obscurity" above knew what he/she meant. It refers to the idea of keeping the design, apparatus and/or methods as well as the keys to a security system secret to avoid compromise. The drawback in doing so means restricting the number of people who can review whether such is actually secure, whereas open review maximises finding flaws. This is "Kerckhoffs's principle" (see https://en.wikipedia.org/wiki/Kerckhoffs's_principle).

By the way, it is not true that "security thru obscurity" is deliberately being done by those monitoring the Tor network for e.g. bad exit nodes.

For "Security thru unpopularity/rarity", I think that's what is better known as "safety in numbers", and is widely practiced by hunted species in evolution. Otherwise, the idea of being arcane conflicts with the desire to make strong security systems common.

Finally, "security thru secrecy" does work, but only for keys!

I believe you do not mean some 'selected' onion nodes can purposely trace/correlate client traffic over the onion network? If so then nsa has it for sure...
Otherwise if you mean modified ip clients and special ip servers then i see no point in mentioning that in the first place.
As about "harvesting onion services" it IS your fault - no one should have access to private information about client-server meeting points. Even directory servers. The only problem - you want to have control over content published by hs! Just see - nsa troublemakers have the same access as ds operators for sure.

Solving the harvesting problem is one of the reasons people are busy working on prop224. Meanwhile, onion service operators can mitigate the problem by using authenticated onion services.

This is the case. “Whenever feasible” is meant to cover software that will run on Tor own infrastructure that would be detrimental to our users in case they got released in the open (this actually covers the binary as well, now that I think abou it). See reply above.

So Tor Project has servers which are protected by closed source software? That's even scarier than the bad exit software. I hope that nothing of this sort runs on the servers which sign or distribute the Tor binaries.

Can you explain exactly how releasing them would be detrimental to the users? If the answer is "analyzing the source code or binary would make us less secure because our adversaries could find holes in it", I will be very, very upset. I hope I am just misunderstanding this quite badly.

Sorry if I was not clear enough. We are discussing what you call “the bad exit software”. To the best of my knowledge, Tor infrastructure is made of free software. (Yes, I'm leaving out the complicated question of firmware here.)

We are discussing internal, peer reviewed software within Tor, that is trying to detect adversarial nodes in the network. Something that is very hard to do if your adversaries know exactly how you are trying to detect them.

Then the code should be re-written such that it takes secret information as parameters or in a configuration file. The code could be released as open source software and could be audited and improved upon by the community, and the configuration file containing information which would enable attackers to evade it could still remain secret. For example, if the secret information includes things such as specific timing patterns to look for, that could be kept in the configuration file. If it contains specific websites or fingerprints to monitor, that could also be kept in the configuration file. It is much less harmful to withhold a configuration file than it is to withhold software. Is there some fundamental reason why this is not possible, or has no one simply done it yet?

The issue of firmware isn't one which I'm concerned about, or at least I don't place blame on Tor Project, because there's not much they can do to run high-end servers without running on hardware that requires firmware blobs (though it would be nice to see some servers run the open source UltraSPARC T2 CPU...).

Mike Perry had designed its initial exit scanner that way. I think for some cases, this configuration file would be almost all the code. We could also consider using git-crypt to restrict access to the relevant part of the sources while keeping others open. But I'm really not sure it's worth the hassle in the end. Little gain, lots of risks to leak important information.

As always, if we had several people solely dedicated, I believe we could come up with interesting ways to solve this problem. We're just super-badly understaffed.

And if we had the open source community, we could easily solve the problem. Sadly the open source community is does not get to work on closed source code. Can you elaborate on why the configuration file would be almost all the code? Perhaps I don't understand how the exit scanner works very well. Certainly explaining the concept behind the scanner itself isn't going to undermine users' security, no? With that information, perhaps I could think of a way to solve the problem and allow the exit scanner to be made more modular, such that it could be improved by the open source community without having its "trade secrets" made public.

"To the best of my knowledge"
Of course tor router modified and closed software still can be free! (: aka nsa does not sell it :) Btw any virus is free. So you are right indeed.
Anyone can modify downloaded source. I wonder why there are so many legacy tor versions on routers. Seems like some work was done to adapt it. I do not say it is bad or good anyway.
But the problem as i see it remains - so cool down fighting little neibours 'adversary' and try pushing nsa to work harder. Any homo sapiens does not use unencrypted connections over naives-net anyway so how much harm can be done by such a little 'adversary'.

"Whenever feasible, ..." surely means publishing source code as resources allow, not policy, right? Whereas it's when "open development would undermine the security of our users ..." that it is policy to be not so open. I don't think this later point in the social contract was actually about source code.

For example, Pluggable Transports and Bridges. Until we have PTs that are too difficult to distinguish from other internet traffic, and bridges that are too important to block when their IPs are known to censors, I suppose that is another area that the Tor Project can't be too open about yet.

Also: Hey, who wants a completely open name and address list of all Tor relay runners!?

Anonymous

September 20, 2016

Permalink

All the comments were deleted? And this is an accident? Really?

Anonymous

August 11, 2016

Permalink

In the words of Steve Gibson who has been doing a weekly podcast called Security Now! for over ten years, "There is no such thing as security!" and secondly, whatever you do, "Trust no one!"

the chain of trust is beginning with you and even if someone is doing the best ; no one can be responsible for :
- a hidden service in the chip (except intel or amd maybe) or
- a backdoor in the o.s (except 'ubuntucastleworst'' maybe) or
- bad coder refusing an audit of the code (except opensource project maybe) or
- insane dev promoting an official spirit of freedom and proposing insecure advices/tools (except the confidence that you offer to an unknown site:contact maybe) or
- corrupted people working in a professional and ethical area but for their own or govt interest (except the recruitment policy maybe) or
- the incredible obscurantism mind which opens the right to read & write with only their permission with exclusively your money and your freedom (except black operations involved in an obscure war for/against terrorism, hackers, harassment maybe) or
- these strange mentalities ... very far that you could name respectful for the privacy/security ... (except the choice of your threat model maybe) or
- an indiscretion (except the lack of culture or education or serious maybe) or
- an outdated , unstable, harmful soft (except a nasty will coming from unsecure place maybe)
" Trust no one " means there are still and always things that you ignore and you must be vigilant and stay well informed and prudent.

I think that's supposed to be "There is no such thing as perfect security!" (otherwise you're saying security is entirely fictional, and that ain't right, right)? Also, are you trusting Steve Gibson when he says "Trust no one!"? Trust has to start somewhere if you're not going to be an island.

Steve Gibson's a smart guy. I believe he isn't against Tor either. I think he wants you to think about the caveats or Tor (and much else), but so do the Tor Project.

Anonymous

August 12, 2016

Permalink

I was willing to help.
I thought about running a tor node... something i did a few years ago with bad results (isp problems, hacker problems, wikipedia problems....)

So I desisted. In your "main volunteer page", under "running a relay" https://www.torproject.org/docs/tor-doc-relay.html.en
Many infos are missing or unclear
For example, I have a slow connection, and I cannot be an exit relay -> I thought I could not help...But then hided in other pages I found this nice and clear explanation.

"So should you run a normal relay or bridge relay? If you have lots of bandwidth, you should definitely run a normal relay. If you're willing to be an exit, you should definitely run a normal relay, since we need more exits. If you can't be an exit and only have a little bit of bandwidth, be a bridge. Thanks for volunteering!"

BTW

I do not have twitter, FB, Google, Yahoo, and my riseup in "on hold". No jabber, no irc. May be I do not like to send paper mail to US too.
Don't U have a Berlin PO Box?
or a bulletin board to post ideas and general questions and suggestions?
How Do I configure IRC to run under tor? in teh website I havent found it already...

You can find

However I find that putting Tor to good use with IRC is almost goddamn impossible, unless you just want to connect to some specific, privacy-oriented servers (like http://y5fmhyqdr6r7ddws.onion/agorairc/ for example), i.e. not servers where all the people are.
More popular IRC servers either block Tor completely, or allow it only if you first register trough clearnet (which kind of defeats the point of using Tor in the first place).
I mean, last I checked, you couldn't even join Tor's official IRC channel using Tor.

I do understand why these restrictions are imposed. I'm merely pointing out that in most cases connecting through Tor just isn't worth the hassle.

Anonymous

August 12, 2016

Permalink

I would like to see something like the following at the top of their goal list:

1. We will never do anything that compromises, or assists in the compromise of, any of our users

2a. We will never not do something that can prevent and/or minimize a compromise of any of our users

2b. We will never not do something that can prevent and/or minimize the assist of a compromise of any of our users

These goals should trump any other goals. I believe the user should always be first and foremost if one chooses to work as a member of the Tor project.

By adding more words, potential issues can arise. The wording can be seen as ambiguous, which presents potential for many loopholes, misinterpretation and misconstruing.

Adding more goals increases the complexity for sorting out the prioritization and weight of each goal. This can impact decision-making.

I think the authors of the statement faced the same conundrum faced by hypothetical honest people who might hypothetically attempt to draft a proposed US federal law relating to technology, while sincerely attempting to frame the language to prevent hypothetical evasion by hypothetical non-USG evildoers while also thwarting the all too plausible (inevitable?) attempts by USG evildoers (whose existence is by now well-established) to misuse the law to pursue their own twisted agenda to the profound detriment of all the peoples of the world.

On the one hand, you should frame the language broadly in order to allow the statement to remain valid in the face of future developments you cannot presently anticipate. On the other hand, if you attempt to make numerous very specific statements, you can never hope to keep the statement up to date, and it will become very complicated and confusing to read.

I also am worried about a few carefully phrased passages which raise some awful suspicions in my mind (so has TP received an NSL or not, and if so, what precisely was FBI demanding?), but on the whole I think TP made the right choice by attempting to state broad principles rather than addressing narrow technical points.

Anonymous

August 13, 2016

Permalink

A social contract is a political statement that clarifies whose side are we on.
Whose side are you on boys?
I stand with torproject and debian, anyday. They are part of the solution, not the problem. They are how networks and the internet should be. Now how do we go about making this a global reality? Obviously if one wants to use tor to make a statement with her/his name they can.

Clearly there are some here who were really "ticked" off by this statement.
Again, whose side are you on boys and girls?