 Okay, please welcome Gustav Björksten. Okay, thank you. Yeah, so my name is Gustav Björksten. I'm the Chief Technologist at the International Digital Rights NGO Access, and we've been running tour servers since 2009. And in the spirit of philosophy, I hope to tell you about some of our experiences. It's going to be fairly high level. And in this talk, I hope to encourage some of you to participate in providing extra capacity to the tour anonymization network. So what this talk will cover, I'll give you a quick introduction to access. And then I'll talk about our experiences with hosting issues, server balance. I won't actually be talking about configuration tweaks. I just put it in there to let you know that that's probably what everyone else would talk about. I'll talk about handling of abuse claims and managing vulnerabilities and user expectations. So access is, as I said, an international digital human rights NGO. We have offices in New York, Washington DC, Brussels in Belgium, Tunisia in North Africa, Manila in the Philippines, San Jose in Costa Rica where I'm currently based. And we have members in India, Kenya, Argentina and Australia, and we're expanding all the time. So our mission is to defend and extend the digital rights of users at risk around the world. And we do that through three approaches. We have a policy approach which hopes to influence legislators and policy makers around the world to put in place legislation that fundamentally protects the digital rights of users. We also have an advocacy arm, and they really have two approaches. One is to run campaigns and try and get grassroots support to put pressure on governments or corporations to do the right thing. And the second thing which we've started doing is lobbying. And so we have two lobbying units. One is in DC for the US domestic area and the other is in Brussels, hopefully to lobby and put pressure on the European Commission to get them to do the right thing there. And what we've found is that those two centres, so DC for the US area and Brussels for European Commission, whatever legislation goes in place there will usually then filter out to other parts around the world. So there'll be data retention laws put in place. And then you'll see them pop up in sub-Saharan Africa or Southeast Asia. And lastly we have a technology arm, and I'll speak a bit more about what the tech arm does. So the main thing is that we run a 24x7x365 digital security helpline for civil society. And so that is primarily assisting journalists, human rights defenders, bloggers, activists around the world, and anything to do in terms of security. So helping them set up secure communications, helping them if they are the victim of a security incident and we help them recover from that and so on. We do a small amount of software development, usually that's in support of the helpline. And the last thing that we do, as I mentioned before, is capacity for the Tor network. So what does that capacity look like? I'll go through some diagrams in the following slides to illustrate. But the Tor network is made up of bridges or entry points into the network, relays and then exit nodes. And as it says there, we have decided to be in the business of exits. And as with everything in the sort of liberation technology space and the space that we operate in, trust is the killer app. And there's nothing like it, there's no app that's going to come close to being able to have trust in this space. And I'll show you how that applies in the Tor network. So this is the Tor anonymizing network. You have a user, when that user uses the Tor network, they're allocated a bridge, which is that entry point to the network. The traffic will bounce around through relays in the anonymizing cloud there. And then the traffic will pop out an exit node to the resource that the user wishes to go to. As you'll notice there, I've marked down the bottom some rogue nodes, a rogue bridge and a rogue exit. We assume that entities that want to defeat the anonymizing purpose of the Tor network are running arrays of bridges and arrays of exits to try and compromise the network. So if a user uses a rogue bridge and they also allocated a rogue exit, then you can do a correlation attack between those and possibly identify that that traffic belongs to that user, which we don't want. That de-anonymizes the network. So what we're looking for is this scenario where, you know, if the user is allocated one, either a bridge that's compromised or an exit that's compromised, that correlation attack should not be able to occur. So this is where I say trust is the killer app. What we really needed is trusted bridges and trusted exits. We don't want anyone running bridges and exits because then you destroy the trust. So access won't run bridges and exits because then we could be accused of being able to do that correlation attack ourselves. And obviously we don't want that. So then just to concentrate on exits to defeat this attack. So learnings. The first thing is hosting issues and the first hosting issue is location. What location to put your Tor nodes in. Now this is a Creative Commons diagram which shows two things. It shows the raw number of Tor users from countries. And it also shows, you know, the density of users in those countries using Tor. So how many per 100,000, you know, internet users in that country. What we're looking at really here is the raw numbers. And as you can see there's a lot of Tor users in the US. There's a lot in Europe, in, you know, Germany, Italy, France and Spain. And the thing is I don't, you know, have the evidence to, you know, directly point to this. But my gut feel is that, you know, Tor is good for those users. Because what we see is that the vast majority of Tor infrastructure is in those countries. They're in Europe, they're in the USA, particularly in terms of Europe here in Germany. And so everything is good and fine. You try and tell someone in Namibia to use Tor and they tell you it's too slow. And that's probably a fair thing because if you look at Africa on that map, it's tiny. There's a tiny number of Tor users there. But is that because they don't know about it? Is it because they're not connected? Certainly there's no shortage of need for Tor in Africa. And likewise in Asia and South East Asia, that's a region of the world that has more than half the world's total population. And it has more than half the total internet users. And yet we see a very small number of Tor users from there. So I think the thing is that we need more infrastructure in different places and places where it currently isn't. So if you're going to run Tor nodes, let's try and put them in those locations that will matter. This is a terribly simplified map of submarine cables around the world. But what it does show is that if you wanted to have Tor servers that were servicing West Africa, it'll give you an indication of where might be good places to locate that. So there's certain points on this map that I think would be ideal to add more Tor servers like Brazil, Singapore, places like that. So keep that in mind. So more hosting issues. Commercial operators, when you approach them and say, I want to run an array of Tor servers, they're like, great, here comes some money. So their default position is always going to be to say yes. Yes, we can serve you. We'll take your money. Again, you go through all effort of building the boxes, configuring them, tweaking them, learning about the environment, and then suddenly they turn them off because there are consequences to running Tor nodes, particularly Tor exit nodes. The first of those is abuse claims. We know that while Tor is a fantastic tool for protecting the identity of users at risk, it is obviously also used by people for nefarious purposes. And so when you run exit nodes, people will be attacked. And if they contact the hosting provider, then that can become an issue. Sustained bandwidth is another issue. So normally when you get some hosting and you put up a website, you might be concerned about the speed of that website and get a large bandwidth allocation. But the reality is that most of the time it's not getting anywhere near that. There might be a few peaks just after lunch, so on. But for the most part, in terms of the hosting provider, it's not an issue. But if you run big Tor exit nodes, for example, it's just going to be solid. It's going to be a solid bandwidth suck. And if the hosting provider is not prepared for that, then that can cause an issue. There's obviously also retribution attacks. So someone gets attacked through your exit node and instead of going through the normal process of notifying the hosting provider and so on. They will just fire up a DOS attack or something. And there can also be pressure from law enforcement. So sometimes we run up Tor servers and it gets shut off by the hosting provider and they won't tell you why. And I kind of suspect that that might have something to do with it. So what can you do? You can certainly explain to them upfront, explain to them what Tor is, explain to them what the consequences might be. But without, again, a trust relationship between you and the hosting provider, it's very, very, very frustrating. You can put in an enormous amount of work to get your Tor nodes running well, only to have them turned off. And you need to monitor access to those servers. The thing is that we want to make sure that those servers are not compromised, so you need to monitor them. So server balance is the next challenge. We started out by taking bare metal servers and just running one node on them and working with that. And then we realized over time that it seemed to go much, much better where we took a bare metal server with a lot of capability and then ran a huge number of virtual Tor exit nodes on top of that. So I can't tell you how much RAM compared to how much CPU and all that kind of thing you're going to need because every environment is different, but you can use a systematic approach to that problem to work out what is best. So there's all your normal resources, bandwidth, latency, CPU memory, disk space and so on. But what you find is that you start to optimize something that's a problem. So let's say it's bandwidth, so you work on that and you get that so that that's kind of optimized. Then you'll start finding that there's a CPU problem or a disk problem. So you just got to keep working at the problem that's closest at hand and hopefully you'll get a nicely optimized machine. As I said before, if you virtualize it gives you more scope in terms of juggling those resources and I think that's what made a lot of difference for us. So when you start to get it right, just, you know, the bottleneck will move somewhere else but just keep going and you'll eventually get a good machine. So you monitor the resources on the machine, monitor the Tor performance. That's obviously important because that's what it's all about. So when you have that information then you can use trial and error. When something starts to work, keep going in that direction. And document, document everything that you do. We had a massive raid array failure and we lost a very large number of nodes and then, you know, we were quickly scrambling to rebuild it and I looked at one of my colleagues and said, right, so get out your notes and let's, you know, configure this thing really quick. And he's like, I didn't take notes. I thought he was taking notes. And it turned out that none of us had taken notes. And so that was, you know, a year of fine-tuning that we then had to go through the process of learning again. So be prepared for catastrophic failure so that you can run them up really quick. Configuration tweaks, as I said before, that's something that gets talked about a lot. Google is your friend. Look it up or come and talk to me afterwards. But I do want to talk about the handling of abuse crimes. So when we started this in 2009 and up to probably the end of 2012, we were frequently visited by men in dark suits and dark glasses. They would come to the office. They had, you know, received some attack against the government or something and they were looking for the culprits. We even had one hilarious incident where we were all, the whole organization was away on a retreat up in the mountains and they'd obviously been trying for days coming through our office and no one was there. So they decided that they would go to the operations director's apartment in New York at 3 a.m. in the morning. But of course he wasn't there. But as you know, apartments in New York, that's valuable space and so he had air being beaded out to someone. And so at 3 a.m. there were six guys in dark suits and dark glasses knocking on the door. He was a bit freaked out. That no longer happens. We really haven't had any of that happen since the end of 2012. So clearly, for whatever reason, the agency is now a rock tour. Whether it's just by a number of cases or whether it's that they're taught or I don't know but that seems to be the situation. So for the recipients or the victims of attacks that are perpetrated through your exit nodes, it's very important how you handle those because I've seen them handled really poorly. And I think we did them poorly initially and we've gotten much, much, much better at it. So you need to explain to them what tour is. You need to acknowledge that tour is the harbinger of malicious attacks and you need to tell them and spend the time going through with them what can be done about it. So mitigating the attacks. There's those things there outbound blocking at your exit node or there's very strategies they can use to prevent traffic either from just your tour exit or from all tour exits going to their resource. But there's a human side to this and we've definitely experienced that human side. We've had people contact us saying they're being stalked. They've been threatened with rape or death threats and all that sort of thing and they're usually very, very upset. So you need to treat them with utmost respect. You need to take the time to listen to them, to work with them, to understand their situation, to explain to them why you're doing it, explain to them what it means to someone in Syria. For them it's a life and death situation. And if you go through that process, the result is usually really good. Resoundingly good. These people usually, if you take that time, will completely do a 180 and will become supporters of tour whereas before they were thinking it was the worst thing that man had ever created. You do have to obviously do the legal bit of covering your ass. And when you have legal people write these things up, they're very cold. So you need to find this balance. We have, as I mentioned, a 24x7x365 digital security helpline. It has the ability to respond to those abuse complaints really quickly which I think is very effective in letting those people know that we care about the situation that they're in. Hopefully we're able to respond in a language that they speak. So that also helps. And you know, this has really become now a crank the handle activity. We run a lot of exits and so we get a lot of abuse complaints but we're able to just crank that handle and get that process moving and explain to them what they can do and so on. And it's usually, the result is very good. There's also the possibility maybe in the future of, you know, using a facility like ours for other operators out there to handle their abuse complaints so they don't have to do it themselves. And lastly, there's the managing of the vulnerabilities and user expectations. I mean, Tor is a fantastic tool but it is not a silver bullet for every threat that needs to be understood both, you know, from the operator's perspective but you also need to educate the users as to when it's appropriate and when it's not appropriate. Okay. Thank you. Okay, and now we have some minutes left for questions. Please use this opportunity. We have two microphones next to the beamers on the left side and on the right side. If you have a question, please come to the microphone and ask. Thank you. Yes, please. So it's not really a question. It's a couple of comments. I'm Lina from the Union. We are a not-for-profit organization running Torx, you know, in France. I'm missing some advices so I'm going to say it then very quickly. Get a lawyer. Have a lawyer work with you if you want to run Torx, it knows. Never run Torx, it knows as an individual or I think it's way, you get much, much better cops reaction if it's legal body as a moral organization than if it's an individual. And have also very prominent contacts like get a fax line because cops send faxes, get a specific voicemail, be ready to handle like visiting person and email. Yeah, that would be what I missed. Excellent. Thank you. That's all fantastic advice. Get a lawyer. Thank you. Somebody else wants to share experience or ask a question. Now it's the time. Hi. I'm sorry. This is not exactly maybe your field, but do you know of anybody running entry nodes like many, many entry nodes instead? So the opposite of what you're doing. Yes, there are projects to run lots of entry nodes. I mean, there was certainly some projects. I don't know what the status of some of them is now. We ran one before we were running exits, which was called the Global Proxy Cloud, which was a cloud of entry nodes. I know that the Tor project themselves did a similar thing where they encouraged people to run up bridge nodes on the Amazon web services. Thank you. Thank you for your question. Somebody else? Hello. On the matter of correlation attacks, you mentioned that you don't want to be running an entry or an exit node in the same entity. Is that true for any combinations? Do you have to make a choice for only entry, only exit, only relay? Yeah. I mean, this is like not in the physical location. We're talking about just an entity. So access as an entity should not run entry points and exit points because then we could be accused of having the capability of doing correlation. And there's no combination at risk when you involve relays. Do you run a bridge in a relay or a relay in an exit? No, it's really the entry and the exit that matters. To map, you know, because you can see certain information at either end to identify the user and at the other end to what they're going to. So that's the danger. It's the entry and the exit, not in the middle. You could still run private bridges for, I don't know, your own people or friends that super trust you and that sort of thing. In terms of, you know, out in the public sphere you should pick one or the other. Claire, thank you very much. Thank you. Another question, please. Yes, you insisted heavily on the fact that the entry point, well, the entry ward and exit node should not belong to the same person, obviously. But if I'm an honest nonprofit setting up Tor nodes, I will set up my family flag and Tor will know that all of those nodes belong to the same person and it will not select two in the same circuit. So I'm sorry, but that makes no sense. Okay, well, let's talk about it afterwards and sort that one out. Now question from the left microphone, please. Thank you. Well, when I used Tor in Europe, it works perfectly but when I had to use it and I was in China it was very slow. I could not, like, exploit it. I had to turn to a VPN. I had to pay for a VPN. So do you have any suggestions like how to overcome this? Do you think that with the passing of time the situation will get better? Well, I mean, you know, this is essentially an arms race but instead of, you know, with missiles it's an arms race on the internet works and the fact is that the Chinese have worked out ways to identify Tor traffic and, you know, they tear the connections down before you can get anything through them. There are strategies to deal with that. There is the obsproxy modules that puts Tor over other protocols to conceal it. You know, your mileage will vary. There are a couple of places where Tor is very, very difficult to get to work. So China and Iran being the two main ones. Thank you very much. Now question from the right microphone. How are you doing, mate? I have a little question about the correlation attacks. I don't know if you know what I was wondering about your thoughts about Astoria, if you're familiar with it. No. We shall talk after then. Okay, great. We have time for two more questions. Last two questions, somebody. Yes, please. If you're considering contributing to the Tor network and you have the bandwidth to spare, what does the network need more of, exit nodes, relay nodes or bridges? That is a very good question. And I would love to know. So what we definitely do need and we have needed for a very long time is more analysis of this exact problem so that we can encourage people to be running up the right types of things to get the right balance of the network. I encourage you all to jump into that research because I want to know. Thank you. And somebody, last question, use the opportunity, ask your questions, share your experience, bring your ideas. Okay, it seems nobody. So for special requests, you can talk to Gustav and enjoy the club and the camp. And yeah, thank you very much. Thank you.