A New Bridge Authority

by isis | September 1, 2016

After ten years of volunteer maintenance of Tonga, Tor's bridge Authority—a piece of critical infrastructure within the Tor network—our colleague and friend, Lucky Green, a long time cypherpunk, and free speech and privacy advocate, has decided to step down from this role. Tonga's cryptographic keys will be destroyed this week. We are incredibly thankful to Lucky for all his support and selfless labour in maintaining a key component of our censorship circumvention efforts, grateful for the years we have spent working with him, and very sorry to see him go.

The Bridge Authority is a simple but essential piece of the Tor Network. Unlike the other directory authorities, the Bridge Authority does not get a vote in Tor's consensus protocol. Instead, it serves to aggregate relay descriptors which Tor Bridges send to it, checking their cryptographic validity and testing that the Bridges' ORPorts within these descriptors are reachable. It then sends these descriptors to BridgeDB, which does all the deduplication, cryptographic signature verification (again), stability calculations, pluggable transport argument validation, assignment into the hashring of each Bridge distribution mechanism, and finally distributing the Bridges to Tor clients.

Number of bridges reported by both Tonga and Bifröst during the bridge authority transition period. Graph by Karsten Loesing.

This transition does not affect Tor users, regardless of whether or not Bridges are used to connect to the Tor network. However, it is extremely important that relay operators running Bridges upgrade to tor-0.2.8.7 or tor-0.2.9.2.-alpha, which contains a patch to replace Tonga with the new Bridge Authority. Bridges which do not upgrade will cease to be distributed to new clients; however, clients which have connected to your Bridge previously will still be able to connect (at least until your Bridge's IP address, port, or fingerprint changes).

"The same thing, but made of rainbows and on fire."

As a replacement for Tonga, I am happy to announce that Greenhost has donated hardware and hosting for the new Bridge Authority, Bifröst. Bifröst is a Norse mythological bridge that connects Midgard, the mortal realm, and Asgard, the realm of the gods, and is described in the poem Grímnismál within the Poetic Edda as a burning bridge, constructed out of a rainbow whose end lies upon Himinbjorg, or "Heaven's cliffs." The name was suggested by both our colleagues Alison Macrina of the Library Freedom Project and Moritz Bartl of Torservers.net. Despite the personal temptation to follow Nick Mathewson's suggestion to christen it after that iconic symbol of my home, I could not help but name it Bifröst, because why go with some boring normal thing, when you could have the same thing, but made of rainbows and on fire. RAINBOWS. FIRE. Clear choice.

The Tor Project is incredibly thankful to Greenhost for their generous donation of hardware, hosting, and bandwidth. In particular, I am thankful to my colleagues at Greenhost, Sacha von Geffen and Jurre van Bergen, for all the work they put into the organisation, collaboration, and technical efforts in setting the server up quickly. Working with Greenhost, as always, is a pleasure, and I would give my highest recommendations for Greenhost to those seeking an ethical, friendly, and experienced hosting provider.

Future Research and Hacking

Moving forward, there are several improvements to these systems which could be made, some requiring further research.

  1. We currently don't have any mechanism for testing the bandwidth capacity of bridge relays. Additional design complications may arise when Bridges have their own Guard relays (#7144), e.g. causing fast Bridges which select slower Guards to not utilize their full capacity. This might be navigated by adding support for bridges to do a self-bandwidth test before selecting a guard node.
  2. We also don't currently have anything that tests the reachability of the address/port for any of a Bridge's pluggable transports. Our previous attempts at a distributed/automated Bridge reachability testing system lead me to believe that there is no way to both reliably and securely, i.e., without literally burning the Bridge by attracting a censor's attention to it, test reachability in a distributed manner. Add on top a game of Russian roulette by mixing in N different pluggable transports with varying indistinguishability, authentication, and security properties merely compounds the issue, adding to the likelihood that the secrecy of the best transport a Bridge provides is reduced to that of its worst. That said, thorough analysis of the risks of a centralised system should be made, and there are likely other alternatives. For example, one might attempt to build a system which heuristically crowdsources this information from clients.
  3. There's no legitimate reason to have the Bridge Authority and BridgeDB be separate systems. It would make more sense to break apart the components into those which
    • receive descriptors
    • conduct reachability tests
    • archive all descriptors
    • access archived descriptors for which Bridges may currently be distributed to clients
    • distribute Bridges to clients in some manner.
  4. Decentralise the Bridge Authority/BridgeDB systems without simply turning a single point-of-failure into multiple points-of-failure.

Researchers and hackers interested in these problems are welcome and encouraged to contribute. If these problems interest you (or your sufficiently bright, self-directed, and motivated students!), please feel encouraged to contact me and/or our Research Director, Roger Dingledine to discuss ideas and projects moving forward.

Comments

Please note that the comment area below has been archived.

September 01, 2016

Permalink

The Ubuntu Xenial package is still 0.2.7.6. Are new packages going to be forthcoming or should I build from source?

September 01, 2016

In reply to isis

Permalink

Got it; I've re-pointed my apt sources and got the new newness.

Thanks for all the good work!

September 06, 2016

In reply to isis

Permalink

Actually, what is written on that page is "that this might not always give you the latest stable Tor version, but you will receive important security fixes." Last part not really true, right? Debian stable repos are still on 0.2.5.12 (April 2015), many moons (and major security fixes) ago.

Please consider updating the documentation to recommend Debian users install from your repo instead and not from debian stable repo.

September 01, 2016

Permalink

You're all modern Aesir! Come to Vanaheim via Asgarth some time and we'll drink mead.

September 01, 2016

Permalink

The dutch government is almost discussing an upgrade of a law which gives them the right to real time wiretap every possible digital communication in holland.
That is all the communication of people in holland and all the communication that is trespassing holland via ams-ix amsterdam internet exchange. Tor project should consider to stop facilitating tor exit nodes and other tor services in holland and the uk because the integrity of communication and tornetwork can not be guaranteed anymore. Nobody knows how many tornodes are already hosted or wiretapped by these governments.
Consider countries that are more to trust.

"Almost discussing an upgrade of a law" sounds a long ways away from legalised. Does this law (and its amendment) have a name? Is there somewhere I might read more?

Also, the design of Tor is such that even if an exit node is wiretapped, the eavesdropper should not be able to learn who the traffic originated from. I'll refer you to the EFF's excellent, interactive infographic for further clarification on who can see/know what information depending on whether you're using Tor or HTTPS, or both: https://www.eff.org/pages/tor-and-https.

September 02, 2016

In reply to isis

Permalink

"Is there somewhere I might read more?"

These links have information about the recently leaked "draft Dutch bill".

MONTH: August 2016, Matthijs R. Koot's notebook, Personal blog
"U.K.: Bulk Powers for for MI5, MI6 and GCHQ – Executive Summary of the Independent Bulk Powers Review", Posted on 2016-08-22:
https://blog.cyberwar.nl/2016/08/ >> Embedded link "draft Dutch bill":
https://blog.cyberwar.nl/2015/07/dutch-intelligence-bill-proposes-non-s…

4 May 2016, BITS OF FREEDOM, VERDEDIGT DIGITALE BURGERRECHTEN
"DUTCH DRAGNET SURVEILLANCE BILL LEAKED: OUR ANALYSIS":
https://www.bof.nl/2016/05/04/dutch-dragnet-surveillance-bill-leaked/

- in spatium

Hey, thanks for the links. While these new developments in the interpretation of the Dutch surveillance laws by Minister of the Interior Plasterk are alarming, in the case of the Bridge Authority, this doesn't really get the Dutch intelligence services anything. The descriptor uploads from the bridges are "tunneled", that is, sent through another (public) Tor relay to the Bridge Authority. Therefore, what the Dutch government sees in this case is a lot of public Tor relays connecting to the Bridge Authority.

These new legal developments are nonetheless unfortunate and grossly unjust—not only that!—but downright dangerous to Dutch citizens who require privacy from prying third-parties, foreign government intelligence services, and petty criminals such as identity thieves. I trust that our friends in the Netherlands—such as Bits of Freedom and other computer security and privacy experts—will continue to protest these developments, offer their expert advice to the Dutch cabinet, and remind Plasterk that his duties as Minister of the Interior and Kingdom Relations include defending the Constitutional rights of the Dutch people, which includes (in articles 10 and 11 of the Dutch Constitution) strong definitions of the rights to privacy and inviolability, including protections against search and seizure of telecommunications data. Additionally, article 10 point 3 guarantees "the rights of persons to be informed of data recorded concerning them and of the use that is made thereof," so it seems like the Dutch government should reasonably be required to inform me and/or bridge operators and/or bridge users, should they decide to record information on the Bridge Authority. I would be happy to stand with other privacy activists in the Netherlands to hold the Minister of the Interior to his duties to uphold the Dutch Constitution.

September 03, 2016

In reply to isis

Permalink

> Hey, thanks for the links.

Plus one.

Reason for cautious optimism: very often the authors of bills ensure that the first draft is a "wish list" in which they ask for the Moon. If there is significant political opposition, very often what they wind up with is nothing, or at most one small corner of some half forgotten crater on the limb of that which makes the werewolves howl.

I hope Tor users in Holland will organize a petition addressed to lawmakers, or at least an open letter of protest. Please see CitizenLabs for many examples of why human rights workers, pro-democracy campaigners, and environmentalists need unbackdoored protective software such as Tor. We are the good guys; the Gammas and Hacking Team malware authors and the torturers are the bad guys, and most dutch politicians can probably recognize this if it is clearly explained. (Obviously you try to reach the moderates, not the neo-nazi fringe.)

Like which other countries would be left? Not the 5-eyes, not the 9-eyes, not the 14-eyes. Not most of South-America, not most of Asia.

Tor doesn't protect against an global adversary. You have to be a pretty big target for them to exploit you though.. Cost/balance, etc.

Finland is increasingly well connected with undersea cables (for its population lol) and still lacks the non-transparent money-swallowing mass surveillance apparatus of neighboring Sweden (FRA). Sadly, much of Finnish traffic passes through Sweden, though.

Of course, the gov't and military intelligence circles are complaining about this "omission" but there's some time left to push packets with the *eyes at least a few hops away. This place could definitely use some more high speed relays.

I just went ahead asked one of the few (semi)sanely priced Finnish cloud providers, Upcloud, if they accept Tor middles/relays and/or exits. Let's see if we get an answer. At least, Upcloud has a reasonably good privacy policy, with their legal/billing entity being based in Finland even though they have data centers around the world.

I know VPSes are overrepresented with DO and OVH, but some smaller hosts in remaining non *eyes countries could at least add some diversity.

https://twitter.com/apecat/status/772091351525711872

Another reason to prefer Finland, from:

https://lists.torproject.org/pipermail/tor-talk/2016-September/042190.h…

> The Finnish Communications Regulatory Authority recommends using encryption
and privacy tools, such as OpenPGP, Signal and Tor :)

Plus Finland has geothermal power and natural cooling, so the perfect locale for green energy servers.

> The dutch government is almost discussing an upgrade of a law which gives them the right to real time wiretap every possible digital communication in holland.

Reference?

Unfortunately, it is all too true that there are in every country those who want to oppress their fellow citizens by constructing a technologically sophisticated neo-Stasi.

But why do you ignore the possibility that a political danger (a move to enact a terrible law) cannot be countered by some lobbying of your own? Surely in Holland there are many who are willing to speak out against such a proposed law? Some who have not forgotten the terrible deeds of the Gestapo in Holland, committed under cover of Nazi "emergency laws"?

Tor Project and Tor users face multiple dangers everywhere in the world: technological, legal, political. And these dangers seem to be multiplying like frenetic rabbits. But we must persevere, and we cannot neglect any category of response to a new danger. We must respond to a threatening proposed new law anywhere where Tor users live with every tool at our disposal. That entails battling in the political arena as well as the technological arena.

Our many enemies are throwing at us everything they possess, and we must respond in kind.

> Tor project should consider to stop facilitating tor exit nodes and other tor services in holland and the uk because the integrity of communication and tornetwork can not be guaranteed anymore.

This proposal reminds me of an oddly counterproductive call for a "strike" by Tor relay operators to protest the firing of a former TP employee who can perhaps not be named in this blog.

(Intriguing rumor: Guccifer 2.0 uncovered a document showing that the US State Department funded Russian internet trolls/hackers to "disrupt" Tor and to perform Gamergate actions. This may explain President Putin's oddly phrased disclaimer about state-sponsored hacking, which seemed to acknowledge extensive cyberattacks by Russians while denying that his government directly pays them. Could the US State Department or CIA have paid Russians to hack the US Congress or a former Secretary of State? Don't see why not.)

Yes, intelligence agencies such as GCHQ actively target the Tor network, but the latest reliable information in the public domain (the Snowden leaks) suggest that as of spring 2013, they were having very little luck attacking specific unknown Tor users. (Maybe the Russians have had more success?) But regardless, we cannot and will not rest easy. But neither can we injure ourselves by abandoning the only thing we have which we have good reason to think works at least some of the time to protect at least some of the People from at least some of the bad guys, namely Tor.

Also, while it is true that GCHQ enjoy easy physical access to IXs in the UK and also to power lines in the UK (c.f. covert power line carrier transmission hijackings), they can and do hack IXs in other countries, and FVEY (and Russian) special forces can at least temporarily gain access to power grids in other countries. So there is not really much reason to think that simply banning Tor nodes which are physically located in certain countries will help make Tor safer.

A few remarks.

AFAIK Tonga was hosted also in The Netherlands, so hosting @ Greenhosting is therefor no change. The tor.dizum.com directory server also is hosted in The Netherlands. So a seizable part of the tor infastructure is located in NL.

Running an Exit server you basically have two things to worry about:

First: liability under criminal and/or civil laws(copyrights fi), this impacts you directly.

Second: interception of traffic by (local) authorities, however this mostly does not happen with the knowledge of the operator so this is outside his influence/control.

The first issue, is not really an issue in The Netherlands, and therefore NL is a perfect location for tor services.

The second issue is (currently) not and issue either. I've worked for a hoster that hosts a lost of tor exit nodes, and these servers have never been tapped. LEOs know how the tor infra work and who is responsible for the traffic (not the operator).

Tapping (exit) traffic should not be an issue in the tor network, (it doesnot interfere with the tor network itself) so if this is your worry let me include some remarks:

France an Germany have an issue with Encryption, encryption is the core of the tor network, any legislation to have encryption weakened, will involve tor operators in these countries.

If encryption cannot be defeated, the next option will be mandatorty back-doors or equipment hacking laws. This means LEO's ad NSA type organisations will have the legal means to either force you to install software or install it themselves with your knowledge. This means they can peek -INSIDE- the tor network.

So if your main worry is wire tapping, please reconsider.

[u]

September 01, 2016

Permalink

Why was there no word on why Lucky Green left?
What about the "Tor Project General Strike" that was posted on the internet (which I am not a fan of, as it leaves whisteblowers and other users who really need tor with less cover traffic)?

Glad to hear that you have replaced the bridge, but I really think you guys should try to fix the community, too.

> Why was there no word on why Lucky Green left?

Here's Lucky's explanation for leaving. Lucky is a very private person, and I do not have any further insight into his reasoning than that statement. I assume that if Lucky had wanted to say more, he would have done so.

> What about the "Tor Project General Strike" that was posted on the internet (which I am not a fan of, as it leaves whisteblowers and other users who really need tor with less cover traffic)?

I agree that the original goal of #torstrike—removing relays from the network—was dangerous for users. It seems the #torstrike campaign was started by someone who is quite angry with The Tor Project for some unknown reason, but that their frankly asinine ideas quickly backfired upon them to instead turn into a "strike against censorship". I'm very proud of the numerous members of the Tor Community who worked to turn #torstrike into a positive movement towards growing the Tor Network and making the internet a safer place for vulnerable people such as whistleblowers, journalistic sources, and political dissidents. While I cannot speak for Lucky, and I know nothing more of his reasons for leaving, I doubt that anyone who has been a contributor to The Tor Project for so many years could ever support a campaign which seeks to diminish the privacy and anonymity protections of those users in need. I suspect that the timing for the campaign was chosen instead by whoever started #torstrike as a attempted coop of independent actions.

> Glad to hear that you have replaced the bridge, but I really think you guys should try to fix the community, too.

Be the change you want to see in the world. ✊

September 03, 2016

In reply to isis

Permalink

> Lucky is a very private person, and I do not have any further insight into his reasoning than that statement. I assume that if Lucky had wanted to say more, he would have done so.

I have no knowledge of this particular case, but just wanted to add:

1. Maintaining something critical for years can over time become extremely exhausting; it is not unusual for someone to simply feel that they have "burnt out" and that someone else should take over.

2. Often busy people with critical tech skills start a family or take a new job, which often leads them to decide that they need to devote to this endeavor the free time which they formerly spent doing something else such as helping Tor.

Handovers of something critical are always nerve wracking, but I have the impression that TP has, thank goodness, somehow mustered the time and energy to perform this one in good order, as noted spy chief Geo. Washington would say.

September 02, 2016

Permalink

Many thanks to Lucky Green for all his contributions, and also to Tor staff for their continuing work trying to get users safe!

As a regular user of Tor, I am confused concerning some essential points about this handover:

o what could go wrong for users if a bridge operator fails to patch to the new Bridge Authority?

o is it safe to continue to use a bridge I have been using recently to connect?

o is it safe to try to obtain new bridges from bridges.torproject.org?

It is very good that the transition is (yes?) being organized outside the US.

Erm... so can anyone state whether or not Tor Project has been served with an NSL? If so, what information did the letter demand and what did the bad guys eventually receive? Someone needs to directly challenge the Unconstitutional gag order which accompanies NSLs by calling a press conference (outside the US!) and revealing everything. Your lawyers will surely give different advice, but I believe DOJ will find some face-saving excuse for backing down from trying to actually put anyone in prison for 65 years because they violated an illegal eternal gag order.

And, uhm, some uncomfortably contradictory advice: stay safe!

Hey, and thanks!

> what could go wrong for users if a bridge operator fails to patch to the new Bridge Authority?

Nothing will go wrong. However, that operator's bridges will stop being handed out to users. The reason is because, if the bridge is still reporting its descriptors to Tonga, and Tonga doesn't exist anymore, then there is no way for BridgeDB to receive the descriptors.

> is it safe to continue to use a bridge I have been using recently to connect?

Yes, that is safe.

> is it safe to try to obtain new bridges from bridges.torproject.org?

Yes, that is also safe.

> Erm... so can anyone state whether or not Tor Project has been served with an NSL?

I personally maintain a warrant canary which covers this. To my knowledge, The Tor Project has never received an NSL, and I certainly have never received one.

Thank you, thank you, Isis! This is all very good news, especially about the absence to date of an NSL, to your knowledge. Possibly you wouldn't know, depending upon what information a hopefully hypothetical NSL demands. But Shari would certainly know, so she would be the best person to address this question with a definitive unambiguous statement.

And please do talk to Shari about a warrant canary. While we all agree, I guess, that this ploy is of limited utility and a royal pain to maintain (you can't ever forget to update it, or the userbase will scream in unnecessary anguish), and could even be exploited by the ingenious evildoers who are continually targeting us*, I think it has value in making it plain that TP is doing everything it can do be a harder target for NSLs.

Thanks again for the specific assurances about bridges. (For the future, if I may: in general, after you write a post it is probably good to add a first paragraph for the unfortunately not-mythical Utterly Clueless newbie, a group which often turns out to include highly experienced regular users who may not be able to easily grasp the gist from a post aimed at a user subpopulation with specific technical knowledge.)

* I suppose you know that someone has apparently posted a fake GPG public key which allegedly belongs to you, and that someone (else?) recently posted in this blog a message encouraging someone (not further specified) to email you a warning that your own warrant canary had expired? Didn't check that and am hip to the whole impersonation thing. This particular incident could be nonmalicious, or a silly prank, but it is likely as I am sure you appreciate that US TLA's are planning something unpleasant for you, so please be cautious without letting paranoia become more of a danger to you than all those spooks. (Alas, we can only guess where to draw the line, of course, and our enemies keep moving the goalposts.)


* I suppose you know that someone has apparently posted a fake GPG public key which allegedly belongs to you, and that someone (else?) recently posted in this blog a message encouraging someone (not further specified) to email you a warning that your own warrant canary had expired? ... This particular incident could be nonmalicious, or a silly prank, ...

Huh? If you're refering to the comment at https://blog.torproject.org/blog/tor-social-contract#comment-200469, that was me! but I don't understand what I've done wrong warning about expiring canaries.

I also wrote https://blog.torproject.org/blog/tor-social-contract#comment-200478.

I was trying to show that warrant canaries are fiddly to maintain, especially if they are to be more granular across time and people. In fact, Isis's canary has expired again:

  1. <br />
  2. gpg: Signature made Mon 22 Feb 2016 12:20:43 UTC<br />
  3. gpg: using RSA key 0x3C9937F994616C82<br />
  4. gpg: Expired signature from "Isis <<a href="mailto:isis@torproject.org" rel="nofollow">isis@torproject.org</a>>" [unknown]<br />
  5. gpg: aka "Isis! <<a href="mailto:isis@riseup.net" rel="nofollow">isis@riseup.net</a>>" [unknown]<br />
  6. gpg: aka "Isis! <<a href="mailto:isis@patternsinthevoid.net" rel="nofollow">isis@patternsinthevoid.net</a>>" [unknown]<br />
  7. gpg: aka "Isis <<a href="mailto:isis@en.ciph.re" rel="nofollow">isis@en.ciph.re</a>>" [unknown]<br />
  8. gpg: Signature policy: <a href="https://blog.patternsinthevoid.net/policy.txt
  9. gpg:" rel="nofollow">https://blog.patternsinthevoid.net/policy.txt<br />
  10. gpg:</a> Critical preferred keyserver: <a href="https://blog.patternsinthevoid.net/isis.txt
  11. gpg:" rel="nofollow">https://blog.patternsinthevoid.net/isis.txt<br />
  12. gpg:</a> WARNING: This key is not certified with a trusted signature!<br />
  13. gpg: There is no indication that the signature belongs to the owner.<br />
  14. Primary key fingerprint: 0A6A 58A1 4B59 46AB DE18 E207 A3AD B67A 2CDB 8B35<br />
  15. Subkey fingerprint: BF8D 1B8E DEBD 985D B29A 8F94 3C99 37F9 9461 6C82<br />
  16. gpg: Signature expired Tue 23 Aug 2016 12:20:43 UTC<br />

So, has Isis therefore received an NSL now? Unlikely. I remember Isis tweeting "I'm busy doing all the things!", which seems to be often the case for her. (Apologies to Isis for any undue fluster caused by me making this canary business so conspicuous.)

Further, are these NSLs as insidious as people might suggest? After looking at two example on the Wikipedia page (https://en.wikipedia.org/wiki/National_security_letter), I think not. First, the requests are limited to requests for data concerning computer records. Second, there is scope to challenge the NSL using lawyers. Third, there is scope to explain that the request is technically infeasible (which is what Tor design is about). This poster noticed this as well: https://blog.torproject.org/blog/tor-social-contract#comment-200595 (second paragraph).

My impression is that the threat NSLs pose to someone like Isis is to ones reputation as someone independent of government, or as someone who does not snitch to the government, rather than being required to backdoor Tor.

Also, if people are worried that NSLs will mutate into something so draconian as to do away with the above countermeasures and allow wider actions such as backdooring even an open source project, may I suggest that we could make the whole ÜberNSL scheme collapse if everyone sends out spoof NSLs everywhere so that no one can tell which are real and which are fake (which you can't do if you are required to keep absolute secrecy).

As for impersonated GPG keys, I read recently somewhere (was it a mail on https://lists.torproject.org?) that all Tor Project personnel have had their keys 'impersonated'. It's not true that the keys are compromised. What happened was that someone recently showed how you can generate millions of GPG key pairs and find ones with interesting last eight octets of the full key ID to look like cool nicknames (See: https://greysec.net/showthread.php?tid=1214). If you compare that to the similar problem of the first seven or digits of onion addresses being easily collided with, one can see that this was inevitable. The only solution (in each case, PGP and onion sites) is: check the full ID.

I personally maintain a warrant canary which covers this. To my knowledge, The Tor Project has never received an NSL, and I certainly have never received one.

isis,

your canary is dead - signature expired a few days ago

hope you're OK. stay safe

September 02, 2016

Permalink

@ Isis:

Ugh, another important research topic which should be taken up by capable trusted people:

Power distribution "smart grids" being installed around the world (EU, FVEY countries, China, Russia, Ukraine, Pakistan, India, Morocco, Turkey, Brazil, Argentina, Korea...). These systems are manufactured and sold (to national, regional, or municipal authorities) by companies such as

o Landis+Gyr (owned by Toshiba Group, the Japanese nuclear-energy defense giant)

o Sensus (owned by Xylem, a US multinational)

o Trilliant Networks (a US multinational)

o Elster

These systems use RF communications to send massive amounts of real-time data from "smart meters" and substation gear to central hubs, which can send commands back to substation gear and to individual smart meters, including commands to shut down a generator, to shut off power to particular buildings or to turn off particular streetlights, or simply to introduce voltage fluctuations on particular circuits.

The makers insist the RF communications are "encrypted" and that control messages are "authenticated". Alas, we know that simply encrypting communications does not suffice to protect a complicated web-acessible system, and that authentications can be spoofed. But there is another danger: power distribution "smart grids" have a built-in communications backdoor, which is well documented in the manuals received by the customer countries but never discussed in public: a second communication modality called "power line carrier transmissions".

Examples of how the bad guys abuse power line carrier transmissions:

o GCHQ uses them to exfiltrate information in cyberespionage campaigns,

o some UPS's (uninterruptible power supplies used to protect servers from power surges) can allegedly be shut down remotely by malicious attackers, using power line carrier transmissions,

o USG special forces allegedly used power line carrier transmissions to maliciously shut off power in a particular neighborhood in order to cause a distraction during the bin Laden raid, without regard for the lives of people who depend upon reliable power for ventilators (for example),

o Russia bought from Elster the same system which had been bought by Ukraine, then allegedly used system manuals and reverse engineering to design the BlackEnergy malware employed to shut down power grids in Ukraine to cover the invasion of Crimea.

So the suggested research topic is to think about how power line carrier transmissions might be used to harm the Tor network, and how Tor can help advise power grid operators to protect against malicious cyberattacks by governments of US, Russia, etc.

In the same vein, how can Tor Project encourage the development of new decentralized power and communication modes?

Even as the bad guys bring up vulnerable smart grids, decentralized solar power is becoming available in some areas, and SDR technology is spreading too. Perhaps if we are clever we can turn these developments to our advantage in terms of enabling citizens and preventing further authoritarian governmental oppression of political dissidents and further technologically enabled suppression of pro-democracy, social justice, and environmental movements.

September 02, 2016

Permalink

"The name was suggested by both our colleagues Alison Macrina of the Library Freedom Project and Moritz Bartl of Torservers.net", please, we all know the name came to you and to those people after watching Thor and The Avengers and other Marvel movies, I doubt you guys are DC fans.

September 03, 2016

Permalink

> it is extremely important that relay operators running Bridges upgrade to tor-0.2.8.7

Then you might want to push that package to the CentOS / RHEL 6 and 7 repository you run.
It's still on 0.2.7.6.

The RHEL/Fedora packages are unofficial; they are created by a volunteer. We do not provide official RPMs. Perhaps you might (kindly) ask the package maintainer for your distro to upgrade? Otherwise, the solution is to build tor yourself and package it via rpmbuild.

It would be really great if someone took up the responsibility of providing well-maintained RPMs for The Tor Project!

September 04, 2016

In reply to isis

Permalink

When did that happen?
To clarify, I'm talking about this repository: https://deb.torproject.org/torproject.org/rpm/el/7/x86_64/
Not the packages distributed via EPEL.

https://www.torproject.org/download/download-unix.html.en doesn't mention that the packages are unofficial.

https://www.torproject.org/docs/tor-doc-unix.html.en still states:
"Similarly, CentOS / Fedora users should use our rpm repository instead."
"Our rpm repository" implied to me that those are official packages, I did not read anywhere that those packages are unofficial / unsupported whatsoever.
I'm not sure I would have used those if I had known that they are not official packages for such a critical piece of software to be honest!

October 04, 2016

In reply to isis

Permalink

deb.torproject is Tor project's domain
a volunteer is packaging Tor and uploading it to your domain and nobody can vouch for it?!
so can a PRC hacker also volunteer to upload custom rpms?!

Toruser50

September 03, 2016

Permalink

For bridge operators who are still running older Tor versions (for whatever reason), is it possible to switch over by specifying an "AlternateBridgeAuthority" in the torrc file? If so, what should that line look like?

September 06, 2016

Permalink

Hey guys,

Wondering if someone more familiar with Tor operation would be willing to clarify this, as I haven't found any serious analysis of the topic.

What would be the impact on the Tor network of a potential compromise of this machine (the Bridge Authority)? Sounds like a central point of failure, but the exact nature of the failure is not very clear to me.
Put it another way, if an adversary had root on the machine, what would be some of the bad things that could ensue?