- tor-project - lists.torproject.org

LWN on the Internet of Onions
by Nathan Freitas 05 Aug '16

05 Aug '16

A good story went up here: http://lwn.net/Articles/695910/ and is getting some props on hackernews as well (https://news.ycombinator.com/item?id=12225998) **** The Internet of Onions By Nathan Willis August 3, 2016 The tension between convenience and security is age-old, but it has, perhaps, never been as acutely felt as it is in debates about the Internet of Things (IoT). Smart devices for monitoring and controlling household and industrial appliances are cheap and near-ubiquitous. But the cheapness and the near-ubiquity of the commercial IoT products on the market both come at the cost of exposing one's devices and home network to eavesdroppers and remote servers. A Tor developer recently undertook an effort to increase IoT security by routing device traffic through the Tor network. While the work is, so far, available only in a single free-software IoT platform, the developers are hoping it will spread. Tor developer Nathan Freitas, who is also Executive Director of the Guardian Project, undertook the the development and testing of Tor-transport support for the open-source home-automation program Home Assistant. On July 20, Freitas explained the project in a blog post. Home invasions In brief, Home Assistant is a Python-based tool that provides a single web interface for a wide range of individual IoT devices. Freitas's contribution is a network configuration that routes Home Assistant's web interface over a Tor Hidden Service (so that it can only be accessed by a Tor-enabled browser via a special .onion domain name). In a demonstration video [YouTube], Freitas calls attention to two separate concerns about commercial IoT devices. The first is that many expect to have direct access to the Internet, often for an HTTP connection to a remote service, and the installation instructions advise users to enable access by simply opening up ports on their firewall (if, indeed, they have one to begin with). The risk is that attackers can easily scan for the signatures known-to-be-insecure IoT products, log them, and access the devices at will. This is rather dangerous, when one considers that IP-based video cameras, climate controls, door locks, and other sensitive devices are exposed in this manner. The second concern is that many products enable device operation solely through a remote web server controlled by the manufacturer; the addresses of these servers may even be hard-coded into the device's software. For the curious, Matthew Garrett has recently taken to writing in-depth reviews of such products on Amazon.com, with both informative and frightening results. Some privacy-conscious users may understandably regard the second concern as the more serious one, since pervasive data logging and user tracking could be taking place at the remote server (not to mention the fact that the device could fail to function without an Internet connection). For many others, however, the first risk is greater. Stories of webcam and baby-monitor exploits are already commonplace; as more device classes go online, one can only expect further attacks. As a result, securing access to the web interfaces of IoT devices has been the initial focus of Freitas's effort. Hiding the route Merely routing the web interface over Tor goes a long way to protect users from the eavesdropping concern, but if the device's front end is reachable through its .onion address, it can still be detected and scanned on the Tor network, as the 2013 paper Trawling for Tor Hidden Services [PDF] explains. The technique described in the paper involves running a large set of Tor relay nodes that secretly log the appearance of hidden service nodes. Although the distributed-consensus model Tor employs makes it difficult for any attacker to shut out the legitimate relays (another possible attack), a well-funded attacker could certainly monitor the availability of hidden services over time and hone in on their locations using traffic correlation. The solution is to enable a little-known "stealth" authorization option in the service's configuration. Setting the HiddenServiceAuthorizeClient to stealth on the server causes Tor to generate a random authorization key pair, so that the public key can be copied to each device that should be allowed to access the service. >From that point on, the nodes in the Tor network provide additional security beyond what would be achievable with (say) a standard HTTP cookie, blocking connection requests from clients without the proper credentials by reporting that the requested server is unroutable. This is possible because Tor hidden services announce their presence to the network by publishing a service descriptor that normally includes the address of an "introduction point" node. The service descriptors are tracked in Hidden Service Directory nodes within the Tor network. Other Tor relay nodes then know how to establish a circuit to the service by looking up the introduction point, even though those relays cannot peek beyond the introduction point to find where the service originates. In stealth mode, however, the introduction-point portion of the service descriptor is encrypted with the private key from the authorization key pair; authorized clients will be able to decrypt the descriptor field because they possess the corresponding key, but other clients will not. Attempts by unauthorized clients to connect to the introduction-point node listed in the service descriptor will fail as being unreachable, making the result indistinguishable from a hidden server that has simply gone offline. There is no limit to the number of authorization keys a server can use, so each client can use a unique key and the keys can be replaced as frequently as desired. Services are also allowed to publish fake service descriptors to further obfuscate connection points from eavesdroppers and trawlers. Secure all the things In an email, Freitas noted that there are two challenges to adding Tor support to a project like Home Assistant. The first is that the program's network layer has to be able to work using an .onion address—which, evidently, breaks many assumptions about host-name formatting and lookup. The second is that the code dealing with the IoT devices themselves is prone to unintended connection leakage. For example, he said, "with Home Assistant there are a lot of outbound connections that it relies on for access to public data that we also want to tunnel through Tor." As is the case with HTTPS support, he added, fixing this is typically a matter of finding developers willing to make sure the Tor routing works. "If we can build a 'LetsOnion' type script to make that easier," he said, "we will." Moving forward, Freitas said he hopes to work on adding Tor support to openHAB and similar open-source home-automation systems. In the meantime, however, he said that users can route individual apps over Tor using the Guardian Project's Orbot proxy for Android. By default, most consumer IoT devices are paired with a one-shot app (one for each brand of light bulb, one for the thermostat, one for the security cameras, etc.). Orbot can tunnel these apps to a Tor endpoint running in the user's home; the result is not as good as complete anonymity, perhaps, but it is certainly superior to trusting the Internet unconditionally. Developers, of course, can also build Tor-routing functionality into the app directly—the Guardian Project's Netcipher library is designed for that purpose. The one remaining piece of the IoT puzzle is what to do about devices that rely on maintaining a connection to a remote web server in order to function. Some such devices can still function with only a LAN connection, which can in turn be routed over Tor. Others, however, fail to function if they cannot "phone home." At that point, the only solution may be to avoid the device in question. Freitas said he was investigating which IoT devices work in LAN-only mode and will try to ensure that they can function when routed over Tor. But which devices go into the home will ultimately remain the user's choice. The security-versus-convenience trade-off has attracted a fair amount of attention from highly technical users, but it remains to be seen whether or not the industry as a whole will ever care. Freitas said he hopes that the Guardian Project's IoT work can demonstrate that the steps required to secure this class of device are small and easy to take, if one is interested in the goal.

1 0

Remove mercurius4 obfs4 bridge from Tor Browser?
by David Fifield 05 Aug '16

05 Aug '16

According to my and Lynn Tsai's bridge reachability measurements, the default obfs4 bridge mercurius4 has not been running for a few months. It was refusing connections in March and April, and more recently has just been timing out. Time to remove it? pref("extensions.torlauncher.default_bridge.obfs4.6", "obfs4 104.131.108.182:56880 EF577C30B9F788B0E1801CF7E433B3B77792B77A cert=0SFhfDQrKjUJP8Qq6wrwSICEPf3Vl/nJRsYxWbg3QRoSqhl2EB78MPS2lQxbXY4EW1wwXA iat-mode=0");

5 8

Re: [tor-project] New Bridge Authority
by Sina Rabbani 04 Aug '16

04 Aug '16

This may just be my own paranoia, but I can't help but to wonder about the level of physical security a "darkened basement" can provide for such a mission critical component of the network. All the best, Sina "Be the change that you wish to see in the world." - Mahatma Gandhi ----- On Aug 4, 2016, at 1:31 PM, isis agora lovecruft isis(a)torproject.org wrote: > isis agora lovecruft transcribed 2.9K bytes: >> Today, I am very excite to take a field trip (!!) to a datacenter (!!!) with >> some most excellent folks from Greenhost (DrWhax and Sacha!!!). We will be >> racking a server and installing an OS on it, and getting it ready to be a new >> Bridge Authority to replace Tonga. > > So… it actually wasn't to the datacenter, but merely to the darkened basement > server room of the Greenhost offices, which Sacha described as "the nicest > office in the building!" > > I've set up the server, bought two new harddisks and configured RAID, > installed an OS on it, and done some preliminary hardening. The server should > go to the datacenter early next week, and then we can start the transition. > It looks like everything should happen well before the 31 August deadline, so > the apocalypse has been averted and there's little reason to freak out. > > Best regards, > -- > ♥Ⓐ isis agora lovecruft > _________________________________________________________ > OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 > Current Keys: https://fyb.patternsinthevoid.net/isis.txt > > _______________________________________________ > tor-project mailing list > tor-project(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

1 0

Please credit NSF in your Tor research papers!
by Roger Dingledine 04 Aug '16

04 Aug '16

When I fill out the annual reports for our NSF projects (SponsorM, SponsorQ, SponsorV currently), I brag about our research papers, and it works much better if we remember to credit NSF in the acknowledgements section of the paper. Here is good text to use: "This work was partially supported by the NSF under grants CNS-1111539, CNS-1314637, and CNS-1520552." More generally, if you are going to be an author on a Tor research paper, including just a submission, please let Kate and me know so we can do good things with this info. Thanks! --Roger

1 0

Re: [tor-project] The Tor Project Social Contract
by Nathan Freitas 03 Aug '16

03 Aug '16

On Wed, Aug 3, 2016, at 04:45 AM, John Gilmore wrote: > Nathan wrote: > > I agree corporate/commercial licensing is a great option for > > sustainable revenue generation. Let's make sure this allows for > > that. In the case of Moxie, his software is not free to developers > > who was to incorporate it into non GPL software. > > The Social Contract is probably not the place to debate (or record > the result of debate about) the specific license used for Tor software. > > Nathan seems to have an issue with GPL licensed software. But his > argument undercuts his point. I have no issue with it, and license as much of my own software under GPL as possible. I agree it creates a great opportunity for licensing revenue that Tor does not have, at least with the core tor daemon. +n

1 0

Re: [tor-project] The Tor Project Social Contract
by Nathan Freitas 03 Aug '16

03 Aug '16

On Tue, Aug 2, 2016, at 02:26 PM, Kate wrote: > I believe that our tools should remain free to users and we should > strategize other ways to make money. "Pay what you can" software is an > idea widely understood in the global north; is it also in the global > south? Pay with what? Bitcoin? Credit cards? If you get the software > installed at your local roadside store, who do you pay? These are all > barriers to using Tor. Just to be clear, if what someone can pay is "nothing" they are free to do so in the "pay what you can" scenario, without stigma. Perhaps we could ask their contribution to just spread the word. Within this contract, I think Mike and I are both just asking for this kind of future option to not be off the table. Perhaps if it is always stated as an "optional donation" then it would fit within the "always free" pledge more cleanly? I agree corporate/commercial licensing is a great option for sustainable revenue generation. Let's make sure this allows for that. In the case of Moxie, his software is not free to developers who was to incorporate it into non GPL software. +n

2 1

Re: [tor-project] Volunteer Application
by teor 02 Aug '16

02 Aug '16

Hi Zaheer, Please reply-all to the list, so others can help you as well. Have you tried building Orbot? https://gitweb.torproject.org/orbot.git You could also look at the Orbot bug tracker, choose a small task, and submit a patch. https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… Tim > On 2 Aug 2016, at 22:03, Zaheer Ahmed <zaheercena(a)gmail.com> wrote: > > Hi > I also worked as Android Developer for Native Apps that's why I am now interested in Orbot. Please Consider it if you can. Again No Demand just offering services for my passion in Security field. Thank you. > > Regards > Zaheer Ahmed > +923351443176 > > On Tue, Aug 2, 2016 at 4:51 PM, teor <teor2345(a)gmail.com> wrote: > > > On 2 Aug 2016, at 19:43, Shari Steele <ssteele(a)torproject.org> wrote: > > > > > > > >> Begin forwarded message: > >> > >> From: Zaheer Ahmed <zaheercena(a)gmail.com> > >> Subject: Volunteer Application > >> Date: August 1, 2016 at 12:11:23 AM PDT > >> To: execdir(a)torproject.org > >> > >> Hi > >> I have been studying Tor from last Several Months and Researching on it now I want to properly get involved in tor Organization. > >> > >> I h'v Spirit, Dedication and also wanted to be. I am a Software Developer worked on Android and core C++ programming. I will not demand Money from you for letting me work in > >> The Tor Project > >> 217 1st Ave South #4903 > >> Seattle, WA 98194 USA > >> > >> Your Reply will be highly appreciated. > >> Regards > >> Zaheer Ahmed > >> +923351443176 > >> zaheercena(a)gmail.com > > Hi Zaheer, > > There are many things you can do as a Tor volunteer: > https://www.torproject.org/getinvolved/volunteer.html.en > > With your experience, perhaps you might be interested in orbot, which provides Tor on Android? > https://guardianproject.info/apps/orbot/ > > Tim > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmmp: teor at torproject dot org > > > > > > Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmmp: teor at torproject dot org

2 2

Fwd: Volunteer Application
by Shari Steele 02 Aug '16

02 Aug '16

> Begin forwarded message: > > From: Zaheer Ahmed <zaheercena(a)gmail.com> > Subject: Volunteer Application > Date: August 1, 2016 at 12:11:23 AM PDT > To: execdir(a)torproject.org > > Hi > I have been studying Tor from last Several Months and Researching on it now I want to properly get involved in tor Organization. > > I h'v Spirit, Dedication and also wanted to be. I am a Software Developer worked on Android and core C++ programming. I will not demand Money from you for letting me work in > The Tor Project > 217 1st Ave South #4903 > Seattle, WA 98194 USA > > Your Reply will be highly appreciated. > Regards > Zaheer Ahmed > +923351443176 > zaheercena(a)gmail.com <mailto:zaheercena@gmail.com>

2 1

Amazon Smile
by Tom Ritter 01 Aug '16

01 Aug '16

Hi all, I noticed that Amazon Smile[0] has Tor Project as a recipient; been using it lately when I order from them. Has anyone collected the money? Is it significant in any way? (I mean anything is helpful of course, I'm just not sure if it's "a couple of tens of dollars" or "a few hundred".) Might be worth tweeting about also, there are firefox/chrome extensions that automatically redirect you so you remember to go through smile.amazon.com -tom [0] https://smile.amazon.com/gp/chpf/about/ref=smi_se_abtpo_r_about_smi

5 4

Summary of meek's costs, June 2016
by David Fifield 01 Aug '16

01 Aug '16

Here's the summary of meek's CDN fees for June 2016. App Engine + Amazon + Azure = total by period all 2014 $600.63 + $917.89 + $0.00 = $1518.52 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 June 2015 $601.83 + $820.00 + $0.00 = $1421.83 July 2015 $732.01 + $837.08 + $0.00 = $1569.09 August 2015 $656.76 + $819.59 + $154.89 = $1631.24 September 2015 $617.08 + $710.75 + $490.58 = $1818.41 October 2015 $672.01 + $110.72 + $300.64 = $1083.37 November 2015 $602.35 + $474.13 + $174.18 = $1250.66 December 2015 $561.29 + $603.27 + $172.60 = $1337.16 January 2016 $771.17 + $1581.88 + $329.10 = $2682.15 February 2016 $986.39 + $977.85 + $445.83 = $2410.07 March 2016 $1079.49 + $865.06 + $534.71 = $2479.26 April 2016 $1169.23 + $1074.25 + $508.93 = $2752.41 May 2016 $525.46 + $1097.46 + $513.56 = $2136.48 June 2016 $0.00 $1117.67 + $575.50 = $1693.17 -- total by CDN $13138.96 + $15778.89 + $4200.52 = $33118.37 grand total https://metrics.torproject.org/userstats-bridge-transport.html?start=2016-0… The number of users dropped a little bit during June, from about 6K to about 5K. If you are one of the users affected by the meek-google shutdown, see here for a workaround: https://lists.torproject.org/pipermail/tor-talk/2016-June/041699.html == App Engine a.k.a. meek-google == 0 GB $0.00 0 instance hours $0.00 https://atlas.torproject.org/#details/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Asia Pacific (Singapore) 219M requests $263.77 660 GB $91.60 Asia Pacific (Sydney) 7M requests $9.74 55 GB $7.51 Asia Pacific (Tokyo) 1M requests $2.09 17 GB $2.29 EU (Ireland) 254M requests $305.11 1636 GB $129.12 South America (Sao Paulo) 16M requests $35.35 178 GB $41.85 US East (Northern Virginia) 129M requests $129.37 1265 GB $99.38 -- total 629M requests $745.43 3813 GB $371.75 charge for alarms $0.50 https://atlas.torproject.org/#details/F4AD82B2032EDEF6C02C5A529C42CFAFE5165… == Azure a.k.a. meek-azure == Zone 1 5926 GB $515.55 Zone 2 434 GB $ 59.95 -- total 6360 GB $575.50 https://atlas.torproject.org/#details/AA033EEB61601B2B7312D89B62AAA23DC3ED8… Earlier reports in this series: https://trac.torproject.org/projects/tor/wiki/doc/meek#Costs

1 0