July 2012 - tor-dev - lists.torproject.org

Proposal 205: Remove global client-side DNS caching
by Nick Mathewson 19 Dec '12

19 Dec '12

Filename: 205-local-dnscache.txt Title: Remove global client-side DNS caching Author: Nick Mathewson Created: 20 July 2012 Status: Open 0. Overview This proposal suggests that, for reasons of security, we move client-side DNS caching from a global cache to a set of per-circuit caches. This will break some things that used to work. I'll explain how to fix them. 1. Background and Motivation Since the earliest Tor releases, we've kept a client-side DNS cache. This lets … [View More]us implement exit policies and exit enclaves -- if we remember that www.mit.edu is 18.9.22.169 the first time we see it, then we can avoid making future requests for www.mit.edu via any node that blocks net 18. Also, if there happened to be a Tor node at 18.9.22.169, we could use that node as an exit enclave. But there are security issues with DNS caches. A malicious exit node or DNS server can lie. And unlike other traffic, where the effect of a lie is confined to the request in question, a malicious exit node can affect the behavior of future circuits when it gives a false DNS reply. This false reply could be used to keep a client connecting to an MITM'd target, or to make a client use a chosen node as an exit enclave for that node, or so on. With IPv6, tracking attacks will become even more possible: A hostile exit node can give every client a different IPv6 address for every hostname they want to resolve, such that every one of those addresses is under the attacker's control. And even if the exit node is honest, having a cached DNS result can cause Tor clients to build their future circuits distinguishably: the exit on any subsequent circuit can tell whether the client knew the IP for the address yet or not. Further, if the site's DNS provides different answers to clients from different parts of the world, then the client's cached choice of IP will reveal where it first learned about the website. So client-side DNS caching needs to go away. 2. Design 2.1. The basic idea I propose that clients should cache DNS results in per-circuit DNS caches, not in the global address map. 2.2. What about exit policies? Microdescriptor-based clients have already dropped the ability to track which nodes declare which exit policies, without much ill effect. As we go forward, I think that remembering the IP address of each request so that we can match it to exit policies will be even less effective, especially if proposals to allow AS-based exit policies can succeed. 2.3. What about exit enclaves? Exit enclaves are already borken. They need to move towards a cross-certification solution where a node advertises that it can exit to a hostname or domain X.Y.Z, and a signed record at X.Y.Z advertises that the node is an enclave exit for X.Y.Z. That's out-of-scope for this proposal, except to note that nothing proposed here keeps that design from working. 2.4. What about address mapping? Our current address map algorithm is, more or less: N = 0 while N < MAX_MAPPING && exists map[address]: address = map[address] N = N + 1 if N == MAX_MAPPING: Give up, it's a loop. Where 'map' is the union of all mapping entries derived from the controller, the configuration file, trackhostexits maps, virtual-address maps, DNS replies, and so on. With this design, the DNS cache will not be part of the address map. That means that entries in the address map which relied on happening after the DNS cache entries can no longer work so well. These would include: A) Mappings from an IP address to a particular exit, either manually declared or inserted by TrackHostExits. B) Mappings from IP addresses to other IP addresses. C) Mappings from IP addresses to hostnames. We can try to solve these by introducing an extra step of address mapping after the DNS cache is applied. In other words, we should apply the address map, then see if we can attach to a circuit. If we can, we try to apply that circuit's dns cache, then apply the address map again. 2.5. What about the performance impact? That all depends on application behavior. If the application continues to make all of its requests with the hostname, there shouldn't be much trouble. Exit-side DNS caches and exit-side DNS will avoid any additional round trips across the Tor network; compared to that, the time to do a DNS resolution at the exit node *should* be small. That said, this will hurt performance a little in the case where the exit node and its resolver don't have the answer cached, and it takes a long time to resolve the hostname. If the application is doing "resolve, then connect to an IP", see 2.6 below. 2.6. What about DNSPort? If the application is doing its own DNS caching, they won't get much security benefit from here. If the application is doing a resolve before each connect, there will be a performance hit when the resolver is using a circuit that hadn't previously resolved the address. Also, DNSPort users: AutomapHostsOnResolve is your friend. 3. Alternate designs and future directions 3.1. Why keep client-side DNS caching at all? A fine question! I am not sure it actually buys us anything any longer, since exits also have DNS caching. Shall we discuss that? It would sure simplify matters. 3.2. The impact of DNSSec Once we get DNSSec support, clients will be able to verify whether an exit's answers are correctly signed or not. When that happens, we could get most of the benefits of global DNS caching back, without most of the security issues, if we restrict it to DNSSec-signed answers. [View Less]

6 12

Help with pf and iOS
by sid77＠slackware.it 28 Sep '12

28 Sep '12

Hi all, it took me a year or so but I've finally managed to build Tor for iOS with a working support for TransPort, as you can see on: https://github.com/sid77/evelyn/blob/master/tor/make.sh The next natural step is to hack together full device torification as iOS jailbroken devices can run pf (without ALTQ support). I'm not very comfortable with pf and pfctl so my first step was to head out to https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy#BSDPF looking for some clue. … [View More]

4 4

First five Tor tech reports
by Karsten Loesing 27 Aug '12

27 Aug '12

Hi Roger, hi Nick, here are the first five metrics tech reports that I'd like to turn into Tor tech reports (see #5405 for the idea behind this). If you agree that this is a good idea, I'll push the sources to tech-reports.git and put the PDFs on the Tor website. I need your confirmation for each report as part of the process, though. - https://people.torproject.org/~karsten/volatile/bridge-stability-2011-10-31… - https://people.torproject.org/~karsten/volatile/blocking-2011-09-15.pdf - … [View More]

6 15

[GSoC] APAF Report
by Michele Orrù 21 Aug '12

21 Aug '12

Hello, As Daniel suggested, I'm writing this email to keep you updated on my Google Summer of Code Project - APAF. Following the hackathon of the 18-21 May, we reached a working build environment, and a primitive administration page. Below follows a brief update about what is the current status of the software: Development: I've defined what a service really is in terms of implementation, and approached the administration service (the "panel") in such a way that any future application may … [View More]

4 15

IRC meeting to plan sponsor L milestones on Wed July 18, 15:00 UTC in #tor-dev
by Karsten Loesing 15 Aug '12

15 Aug '12

Hi everyone, we have an upcoming sponsor contract starting on October 1, 2012 and running until August 31, 2013. To be precise, this contract is not signed yet, but it's very likely to happen. The general deliverables are already defined, but we can suggest which parts we plan to have done by which milestone. The deliverables can be found here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorL I suggest we have an IRC meeting with all developers who'll be involved in … [View More]

5 12

[GSoC] Stegotorus
by vmon 04 Aug '12

04 Aug '12

Hi there, The payload strategies can be changed easily now by inheriting different class from PayloadServer. Current strategy is now in TracePayloadServer. For ApachePayloadServer strategy, server side is complete. for the client side, I need a handshake in steg level so the server sends the client, url dictionary. This needs to manipulate the program in level of Chop protocol. I spent few days to add this capability where chop send a reply handshake to the client (based what is in the … [View More]

3 2

How to best support tor 0.2.3.x in Tor Browser Bundle?
by Mike Perry 01 Aug '12

01 Aug '12

Quick recap from #tor-dev IRC convo with Nick, Roger, and Andrew: We need to get a usable tor 0.2.3.x-rc bundle out RSN so we can declare it "stable", but there are concerns that using Firefox 14 with this will continue to cause unexpected problems and otherwise scare people away from testing tor 0.2.3.x enough. However, I still need to have a place to commit TBB-alpha patches, and have three bugfixes (including a fix for a FF14 crash bug that was discovered by tor-qa) that I'd like to get … [View More]

4 4

[Stegotorus] chop server to client handshake and the url dictionary
by vmon 31 Jul '12

31 Jul '12

Hey Zack, I'm working on changing how client sends info to the server for ApachePayloadServer, according to our discussion. This is how it's going to be for now. The server sends a list of file in some order to the client at the begining of the conversation. The client will send its coded request by chosing a url a from the list and a parameter that it sends to that file such as: /groups/watch.cgi?param=QTwFt25 For this I need to send the list of files somewhere to the client. I looked at … [View More]

2 1

Trip Report: Defcon
by Damian Johnson 31 Jul '12

31 Jul '12

Hi all. When tor developers go on trips we commonly write a trip report afterward. My recent trip to Defcon didn't contain anything sekrit so sending the notes I took here. If any of these presentations sound interesting to you then videos should be available later on the Defcon site. Cheers! -Damian PS. I was new to many of the things being presented so my notes quite likely have some inaccuracies. Don't quote me on anything - watch it for yourself if interested. tl;dr Only presentations … [View More]related to the privacy field were... * Can You Track Me Now? Panel discussion on mobile GPS tracking with lots of interesting stats. * Crypto and the Cops EFF presentation on the 5th amendment protections and how it applies to compulsory decryption. ======================================== Las Vegas is... an unusual city. Like most people I knew I wasn't in Kansas any more when I saw slot machines in the airport. By day the city's not much to look at. Mostly just a bunch of dusty buildings baking in the 110 degree desert heat. But by night the whole city illuminates in neon lights making it quite a spectacle. My first night I explored the strip and several of the larger casinos including Bally's, Bellagio, Caesar's Palace, and the Rio where the conference was taking place. They were... enormous. Caesar's in particular took me almost a half hour simply to walk the length of it. Probably my favorite sight was the Bellagio fountains which had a magnificent water show choreographed to 'Singing in the Rain'. It was very classy. ======================================== The second day was the first of the conference and mostly consisted of two things: standing in line a couple hours for registration and introductory talks. The talks were just a single track and included... * Wireless Security: Breaking Wireless Encryption Keys Handshake process for WPA, WEP, and WEP2 among other things. I was still sorting out the material that I got during registration so I didn't pay very close attention which was a pity since I could use a refresher. * Intro to Forensics: Tools & Tactics A very brief introduction to nmap, tcpdump, netcat, ntop, and Metasploit. Nothing new to me here though it was a nice reminder that I know less about them than I'd like. I haven't played with them since grad school and should try them again when I get home... * Cerebral Source Code Presentation on social engineering. Sadly missed a large part of this one since I still hadn't had breakfast. The QA portion that I saw was fun, mostly questions about how he'd extricate himself from various sticky situations. His answers were clever, as well as entertaining. My favorite... Q: What would it take to have more trust in this community? A: LSD? * DC101: Defcon Survival This was a panel discussion with general advice for enjoying Defcon. Mostly it boiled down to 'you get what you put in' which caught me a little off guard. I came here expecting to watch some talks, see Vegas, and schmooze with other conference attendees. Defcon, however, aims to be a lot more interactive than that and the organizers put a lot of effort into events that weave throughout the conference. * HF Skiddies suck, don't be one. Learn some basic Python. This one made me twitch. The speaker both gave a very bad tutorial for getting started with python (who the hell fires up *Eclipse* every time they want to write python?!?) and seemed to be incoherently drunk for most of it. Mostly I spent this time reading the program. * Hacking the Hackers: How Firm is Your Foundation This was a long checklist of various topics the speaker thought the Defcon audience should know about, largely focused on hardware hacking since that was his specialty. Interestingly 'TOR' was the first thing he listed. I always wondered how that spelling persists despite our efforts to stamp it out. Considering that this conference had roughly 20,000 attendees, each of whom will pass it along I guess now I know... * Fun with the Lockpicking Village A few years back I read the MIT guide to lockpicking and spent a couple days practicing against my door. Since then I've fallen out of practice and this was a nice reminder about both the basics and a few things that I didn't know (how bump keys work, defeating deadlatches, how to use a can of compressed air to defeat magnetic locks that allow egress traffic, etc). The hallway track wasn't anything too notable. Met three developers with Metasploit and someone from the security group I attended at WSU. But that was about it. ======================================== Second day of the conference I ran into someone from Amazon Infosec. A talk I wanted to attend concerning the attack surface of near field communication (NFC) devices was full, but several of the others were interesting... * Can You Track Me Now? This was my favorite presentation of the whole conference. A panel of four presenters, including Chris Soghoian, discussed geolocational privacy of mobile devices including local threats, historical information, and requests for real time tracking. Why does this matter, you ask? Because when it takes a team of agents to track your every step surveillance is costly. But when a single agent can track you and your every acquaintance from the comfort of his desk we get a whole lot closer to a 1984 style surveillance state real fast. Sprint now has a department of 200 people to service wiretapping requests. They also provide a self-service portal to law enforcement that has been used six to seven hundred thousand times a year, for 8 million GPS coordinates. This includes your every move going back 6 months to 2 years depending on your provider. 7 years in the case of AT&T. And no, none of this requires probable cause or a warrant. In other words, beware if your ex is a cop. Another eye opening bit of the talk was phone encryption. Apple has a master skeleton key for all iPhone devices so, when requested, they can send law enforcement a DVD with all the contents of your phone. Android is a little different in that they remotely reset your password to something that they can give the law enforcement agent. Beside three letter agencies, ad networks and apps are also a concern. 47 of the top 100 mobile applications send locational information to 3rd parties. For instance, 'Best Alarm Clock' sends locational information in the clear to 3rd parties whenever the app is used (somehow I doubt they need to do that for the alarm clock to function...). On a policy front one slight glimmer of hope comes from a recent case which ruled that placing a GPS tracking device on your car *does* constitute a search and hence requires a warrant (which means they kinda sorta need evidence of wrongdoing, *gasp*!). Don't read too much into this, though. The majority opinion ruled this way because it technically constituted trespassing on your property. Just because you're paranoid doesn't mean they're *not* out to get you... * Crypto and the Cops Marcia Hofmann from the EFF discussed 5th amendment protections and how they apply to being compelled to reveal your passphrase for an encrypted device. There have been five cases in this area so far, some that ruled each way in terms of compulsory decryption. Though not intuitive, the main determining factor in those cases constituted a gap in knowledge. If law enforcement knows exactly what they're looking for and where it is then there's less chance of the amendment applying than if the search is a fishing expedition. Moral of the presentation: never volunteer information, even if you're innocent. Ask for a lawyer first. * Making Sense of Static Walkthrough of GPS signal acquisition, mostly focusing on how receivers account for Doppler shift and determine the code phase. The speakers also presented libswiftnav, an open source implementation of a GPS receiver system. * Life Inside the Skinner Box Cautionary presentation about the automation of law enforcement and where it might someday lead. This was pretty high level, discussing the societal implications. * Anti-Forensics and Anti-Anti-Forensics Discussion by a forensic examiner of several tricks that can draw out the length of an investigation (and by extension cost, increasing the chance of settlement). He also covered how they can be mitigated. Some of them included... - using a non-standard RAID configuration - randomizing file crated/modified timestamps - altering file header types - using restricted windows filenames (CON, PRN, AUX, etc) - owning lots 'o media - modifying files provided with your system so the checksums no longer match what a default install would include (and hence adds to the haystack of things to sift through) Before heading back for dinner I also caught part of a Skytalk. I didn't find the presentation to be too interesting (brainstorming about mass data aggregation), but I got a chuckle from the sign on the door: "Absolutely no cameras allowed. Violaters will be violated violently." :P ======================================== I had less luck on the third day of the conference, hopping between several talks that weren't particularly interesting. The best I found were... * World War 3.0 - Chaos, Control, the Battle of the Net Policy talk about Dubai's upcoming WCIT negotiations (aka, the thing that's gonna politicize the Internet). Most of the presentation was surprisingly fluffy, the only interesting bit coming from Dan Kaminsky who made the point that there's generally four interests involved... - privacy - security - anti-piracy - sovereignty ... with 'reliability' being the golden goose that no one wants to cook. His point was simply that these four camps war and forge alliances, privacy and security for instance sometimes at odds over anonymity but thick as thieves on other obvious fronts. He also said something like "We have made a system optimized for moving pictures of cats. And it's *really* good at it. Though we'd like it to do more." (likely horribly misquoted) * Exploit Archeology: Raiders of the Lost Payphone Step by step process of reverse engineering and reprogramming an Exetel payphone. Twenty year old software from a company that imploded without a trace long, long ago. Ye gods each step turned out to be a trek to Mt. Doom and back... * Off Grid Communication with Android Mesh network by introducing a transparent proxy after going through the Java networking interface. He wrote something based on the 'Wi-Fi Tether for Root Users' app to put his phones into ad-hoc mode then tried both the OLSR and BATMAN proactive routing protocols. He also tried a reactive protocol that broadcasts messages, then left routing decisions to the receiver which can trivially pick the shortest path though this had issues scaling above 200 devices or so. * Back Ops My favorite talk of the day, given by Dan Kaminsky. It was originally slated for two hours, but got crunched at the last minute into a one hour slot so he went pretty fast over five different topics including... - Timing Attacks Attacks can distinguish 15-100 ms deltas over the Internet and 100 nanoseconds over a LAN. Making everything take an identical amount of time is generally unrealistic since it forces everything to worst case performance. His view was not to let the perfect be the enemy of the good, and simply introduce random delay into requests. - Bad Random Number Generation First a rant that for twenty years security engineers have worried about entropy sources, yet we still haven't gotten it right. The common sources of entropy are: hardware RNG, keyboards, mouse, and disk rotation. However... most servers don't have any of these, especially with the move to virtual storage devices. Roughly 1/200 keys on the Internet are poorly generated, and he proposed using idiosyncrasies in clock timing as an alternative source of randomness. - Security Aspects of Languages Starting with the question 'why is PHP so damn popular?', he discussed why secure coding practices like prepared statements often aren't followed. His conclusion: SDEs are in charge and they just want their service to work. The more of a pita security makes itself the more it'll be viewed as an obstruction and hence circumvented. He then proposed more usable security patterns, for instance making the languages smart enough to translate queries like "SELECT name FROM users WHERE username=$id" into the proper prepared statement counterpart. - Censorship Detection After a brief mention of OONI-Probe he discussed a censorship detection method of his via the use of favicons. I saw this in an earlier presentation of his and he mostly skimmed through it. - Vulnerability Scanning Trying to answer the question of 'how much of the Internet is vulnerable to X', he used *stateless* TCP connections to scan hosts far quicker than he usually could. The trick was to skip retaining any information about outbound connections, making fire-and-forget TCP handshakes and leaving it to the other end to remember the state of the connection. ======================================== I didn't expect much from the lineup on the last day, but some of them were surprisingly good. I also ran into a couple more people from Amazon and Runa very briefly. * SIGINT and Traffic Analysis for the Rest of Us Very good talk on APCO Project 25 (P25), two way radio communication used by police, fire departments, federal enforcement, the secret service, and the DoD. A drop-in replacement for analog FM, this was first introduced in the early 1990s. It can optionally be encrypted, with federal/DoD users commonly enabling it and police/fire leaving it off. If you see an earpiece or bulky walki-talky then this is what it's probably using. The speaker discussed several vulnerabilities in P25. Firstly, it uses a forward correcting protocol that is easy to jam. Usually a jammer needs to be stronger than the signal it's jamming, but with P25 it's sufficient to selectively block a message's header to cause the rest of the message to be ignored. How hard is this, you ask? To cheaply jam a P25 signal you just need a $15 GirlTech IMME toy (it cost less to buy the toy than the transmitter that comes in it). As an added bonus it comes in pink or purple and comes with ponies on the box! Second, P25 has no notion of authentication. Anyone can transmit and user ids can be trivially spoofed. The user id of transmitters are sent in the clear, even when encryption is enabled. Third, any P25 device that receives a malformed signal will reply with the user id (again, in cleartext). This is invisible to the user and means that you can ping all P25 devices and triangulate their positions. Think of it as the "Marauder's Map" for the secret service. Fourth, P25 is a narrow band radio broadcast (12.5 Khz) which is fairly easy to intercept via a scanner (such as an Icom R-2500). This makes encryption a must for private communications. However, the encryption of P25 devices has several usability issues... - Encryption is enabled or disabled via a switch on the handset. The only indication of if encryption is enabled or not is a "1" or "(/)" symbol on the handset. Which means 'encrypted' and which means 'cleartext' is evidently a common point of confusion. - The beep that the device makes to indicate that it's in encrypted mode is the same that's used to indicate a low battery among other things. - Encryption is transparent to the receiver, so if an individual in a group is broadcasting in cleartext then it's impossible for anyone else in the group to know and correct them. - Rekeyed P25 devices become incompatible while being rekeyed, forcing users to drop to cleartext if any of the devices haven't yet been updated. As a result, about 30 minutes per day of federal communications are sent in the clear. In a multi-city study on what this included researchers were able to gather the names of informants, license places of vehicles being tailed, etc. These snippets were also enough to reasonably figure out what investigations were going on at a given time. When brought up with the federal field offices encryption rates improved for a week or so, then dropped back to their prior ratio of cleartext. The researchers also discussed these with the manufacturers, who insisted that it wasn't their fault if their users couldn't properly use their devices. Btw, the only federal service to have a spotless record in terms of encrypting their communications? The US Postal Service. * SCADA Strangelove or: How I Learned to Start Worrying and Love the Nuclear Plants This was a talk on the security of SCADA HMI software (or lack thereof), which is used throughout several minor things like nuclear power plants. Originally to prevent plant operators from installing pong on the kiosks, HMI applications hasn't evolved much since those humble origins. This talk was funny as hell, going over issues with several widely deployed HMI systems... - Microsoft Bob: Early attempt at a friendly, 'helpful' interface. If you made three incorrect password attempts you got a dialog saying "I see you forgot your password. Please enter a new one here...". It also stores passwords in plaintext. - InvisiLink: Stored passwords are an xor with a static key. What is that key, you ask? "0123456789" - KingView: Passwords simply have their last byte subtracted from 0xff. - Iconies Genesis32 9.2.2: The login dialog includes a 'challenge code' that can be used as an alternative method of getting local admin access. To use this code the user is supposed to call customer service, who then provides the password corresponding with the code. Alternatively, you can take the first eight characters of the challenge code's md4 hash to do the same. There were also a couple talks on 'firesheep inspired' frontends for various exploits. The first did NTLM relaying against Windows corporate networks to allow for a variety of not-so-nice things like reading through another person's Exchange inbox. The second was a UI to automatically ARP poison a network then use sslstrip to snag credentials. I felt a little embarrassed for the speakers in this talk since they first tried to sensationalize what sslstrip could do. After that they claimed to have a stealthy MITM, then described the noisiest attack I can think of. Not only did they ARP poison the network and do SSL downgrading, but they did a nmap scan of every host on the network and, just for added stealthyness, blocked all tunneling protocols (ssh/vpn). The later was on the theory that "they'll just use the local network instead". Uggg. So more annoying push-button solutions for script kiddies. Yay. ======================================== Ending conclusions: Fun and interesting conference, but *damn* vegas is pricey. The trip was 1.5k and only $200 of that was the conference registration. I enjoyed it and it was a good thing to do at least once, but way too costly to do again. [View Less]

1 0

Re: [tor-dev] Def Con Kaminsky talk (censorship detection)
by David Fifield 31 Jul '12

31 Jul '12

Dan replies: On Mon, Jul 30, 2012 at 11:33:09AM -0700, Dan Kaminsky wrote: > Basically, if you spoof HTTP or HTTPS headers from a Flash socket to your own > IP, with someone else's Host/SNI, a transparent proxy is going to send its > interposing content to the Flash SWF and not to the browser. It's a really > deployable way to see nasty stuff. > > One warning is that if hijacking is DNS based, and not transparent proxy based, > you don't see anything with this stunt (… [View More]

1 0