 I welcome you to Tor Onion Services, more useful than you think. This talk is presented by George, who is a core developer of Tor, and he's also a developer of the Hidden Services. By David Goulet, who is a developer for the Tor Hidden Services. And by Roger, who is founder of the Tor project and MIT graduate, and the foreign policy magazine calls him, he's one of the top 100 global thinkers. I think that speaks for himself. Today we will hear examples of Hidden Services for really cool use cases, but also we will hear about security fixes that make the Hidden Services even more safer and stronger for all of us. Stage three for Tor Onion Services, more useful than all of us think. Great. Hi. I'm going to pause while we get our slides up, I hope. Hopefully that will be a quick and easy event. Perfect. Okay. So, hi. I'm Roger. This is George. This is David. We're going to tell you about Tor Hidden Services or Tor Onion Services. They're basically synonyms. Originally they were called Tor Hidden Services because the original idea was that you hide the location of the service, and then a lot of people started using them for other features, other security properties. So we've been shifting to the name Onion Service. So we'll switch back and forth in what we call them. So a spoiler before we start, this is not a talk about the dark web. There is no dark web. It's just a couple of websites out there that are protected by other security properties. So we'll talk a lot more about that. You can think of it as HTTPS is a way of getting encryption and security when you're going to a website, and .Onion is another way of getting encryption and security when you're going to a website. So journalists like writing articles about the huge iceberg with 95% of the web is in the dark web. That's nonsense. So we're going to try to tell you a little bit more about what actually is Hidden Services and Onion Services and who uses them and what things they can do with them. So how many people here know quite a bit about how Tor works and what Tor is and so on? I'm hoping everybody raises their hand. Awesome. You can skip all of that. Perfect. So Tor is a U.S. nonprofit. It's open source. It's a network of about 8,000 relays. One of the fun things about Tor is the community of researchers and developers and users and activists and advocates all around the world. Every time I go to a new city, there's a research group at a university who wants me to teach them what the open research questions are and how they can improve, how they can help to improve Tor. So the basic idea is you have your software. It pulls down a list of the 8,000 relays and it builds a path through three of them so that no single relay gets to learn where you're coming from and where you're going. And you can see up at the top here, there is a .onion address. So basically Hidden Services or Onion Services are in your browser, in your Tor browser. You go to an alternate type of domain name that ends in .onion and then you end up at that website. So here's an example of a riseup.net website which we are reaching using the onion address for it rather than black.riseup.net. Okay, so I talked about the building block before, how you use Tor normally to build a three hop circuit through the network. Once you have that building block, then you can glue two of them together. So you've got Alice over here connecting into the Tor network and you've got Bob, the website connecting into the Tor network and they rendezvous in the middle. So Alice is getting her anonymity, her three hops inside Tor, Bob is getting his anonymity, his three hops inside of Tor and they meet in the middle so Alice doesn't know where Bob is, Bob doesn't know where Alice is and the point in the middle doesn't know either of them yet they can reach each other and get some cool security properties. So some of these cool security properties, one of the really cool ones is that that dot onion name that you saw with the base 16, base 32, big pile of 16 characters, that is the hash of the public key, which is the onion service, which is the onion address. So they're self-authenticating meaning if I have the right onion address, I can be sure that I'm connecting to the website, to the service that's associated with that key. So I don't need some sort of certificate authority model where I trust Turkish telecom to not lie to me, it's all built in self-authenticating, I don't need any external resources to convince myself that I'm going to the right place. Along with that is their end-to-end encrypted. So I know that nobody between my Tor client and the Tor client on the service side is able to read or intercept or man in the middle of the traffic. So there are some other interesting features also, one of them is the NAT punching feature. If you offer an onion service, there's no reason to allow incoming connections to it, so I can run an onion service deep inside the corporate firewall or behind Comcast's firewall or wherever I want to and people are able to reach it. So there are a lot of people from the systems administration side who say, I'm going to offer an onion address for my home SSH server and now the only way that I can connect back into my home box is via the Tor network, I get end-to-end encryption, I get self-authentication and there's no other way in, I just firewall all incoming connections and so the only surface area that I expose to the world is if you're using my onion address you reach my SSH port, I don't allow any other packets in of any sort. So that's a cool example of how security people use onion services. So hello. We have some statistics for you to show you the, to give you an idea of the current maturity of the system. We got these statistics by asking relays to send us information about the hidden service activity they see. Only a small fraction of relays is reporting these statistics, so we extrapolate from this small fraction and so that's why these statistics can have lots of ups and downs and noise and everything, but anyway, it can give you a basic idea. So this first statistic is the number of hidden services on the network and you can see that it's about 30,000 hidden services, give or take, and it's a pretty small number if you compare it to the whole Internet, I don't even know, it's basically in the early adoption stages. And we also have another statistic, this one, which is the traffic that the hidden services are generating basically on the top, you can see the total traffic that the whole network is pushing, it's about, I don't know, 60,000 megabit, and the bottom graph is the hidden service specific traffic and you can see that it's like 1,000 megabit, like a very small fraction basically. So hidden services are still a very small part of Tor and if you don't understand this number thing very well, we did some calculations and stuff and we have this new figure for you, which is that basically 5% of client traffic is hidden services, from the whole Tor, 5% is hidden services basically. I don't know, you can handle this as you want. So and we did this whole thing like a year ago and we spent lots of time figuring out how to collect statistics, how to get from the values themselves to those graphs, how to obfuscate the statistics in such a way that we don't reveal any information about any clients and we wrote a tech report about it that you can find in this link if you're interested in looking more how the whole thing works. And we even wrote a proposal, so I don't know if you Google for Tor project, proposal 238, you can find more information and yeah, that's that. Okay, so how did this whole thing start? We're going to go through a couple of years at the beginning. In 2004, I wrote the original hidden service code and I basically wrote it as a toy. It was an example. We have this thing called Tor and use it as a building block. Look what we can do. You can connect two Tor circuits together and then you can run a service like this. And basically nobody used it for a few years. One of my friends set up a hidden wiki where if you run an onion service, then you can go to the wiki and sign up your address so that people can find it. And there were some example services. But for the first couple of years, it basically wasn't used, wasn't interesting. The first really interesting use case was the Zyprexa documents. So this was in 2005, 2006. There's a huge pharmaceutical company called Eli Lilly and they have an anti-psychotic drug called Zyprexa. And it turns out that it was giving people diabetes and harming them and killing them and they knew about it. And somebody leaked 11,000 documents onto the internet showing that this drug company knew about the fact that they were harming their customers. And of course the drug company sent a cease and desist to the website and it went away and it came up somewhere else and they sent a cease and desist and it was bouncing around and suddenly somebody set up a Tor hidden service with all of the documents and Eli Lilly had no idea how to send a cease and desist to that address and a lot of people were able to read the corruption and problems with this drug company. So that was on the one hand, yay. On the one hand that's really cool. Here we are, we have a censorship resistant privacy thing, somebody used it to get information out about a huge company that was hurting people, great. On the other hand, it set us up wherever after people looked at hidden services and said, well, how do I find a document that some large organization is going to be angry about? I'm going to set up a website for leaking things. I'm going to set up a website for something else that the man wants to shut down. So the first example of hidden services pointed us in a direction where after that a lot of people thought that that's what hidden services were about. So that leads to the next year, WikiLeaks set up a hidden service for their submission engine and it's not that they wanted to hide the location of the server. The server was in Sweden, everybody knew the server was in Sweden, but they wanted to give extra security to users who are trying to get there. One of the really interesting properties that they used from hidden services is the fact that if you go to the .onion site from your normal browser, it totally doesn't work. And this was a security feature for them because they wanted to make sure that if you're a leaker and you're doing it wrong, you're configuring things wrong, then it totally fails from the beginning. They wanted to completely remove the chance that you accidentally think that you're using Tor correctly and being safe when actually you screwed up and you're not using Tor. So they wanted to use onion services as another layer of security for the user to protect the user from screwing up. Now fast forward a couple more years, there's another organization in Italy called Global Leaks where they've set up basically a mechanism where if you have something you want to share with the world, then you can be connected to a journalist through this Global Leaks platform and they actually have been going around to governments convincing them to set up Global Leaks platforms. So they've gone to the Italian government, they've gone to the Philippine government and basically they say, look this is a way for you to report on corruption, to hear about corruption inside your country. Now if you go to a government and you say, I hear there's corruption, here's a way to report on it. Not everybody in the government will be happy with that, but one of the features is you can very easily say, can you help me set up an anti-corruption whistle blowing site for the country next door? I would be happy to, you know, they've got corruption, so how about they provide the corruption site? So it's really cool that Global Leaks is playing the political game, trying to demonstrate that making these things public is worthwhile. And of course, here's our picture of a cute cat, we have to have one of those. And Wild Leaks is a really good example of a positive, I mean, this is a way where if you see somebody killing rhinoceros or elephant or something in Africa and you know about it, upload it to Wild Leaks and then they can learn more about poaching and extinction events and so on. So it's hard to argue with anti-poaching, anti-corruption sites like that. And that moves us to Secure Drop. There's a group in the U.S. that is working on another example of how to connect people with interesting information to journalists who want to write about it. And they've actually connected with the New Yorker and a lot of high-profile newspapers to be able to provide a way for people to securely provide information to those journalists. And they say that it has been used in high-profile events and they won't tell us which events, which is great. That's exactly how it's supposed to work. Hello. So continuing our timeline here, this very cool thing happened in 2014 where FX Twin, this electronic experimental guy, released his album, Cyro, through a non-unit on Twitter and it got 4,000 retweets. So we encourage you guys to consider this method of releasing all your stuff and then the complementary ways to release it will be the open web, so on your addresses. Following that, we got blockchain recently in 2014, let's say two years ago. They discovered that for security concerns, when you're using Tor, the exit nodes, some malicious exit nodes were rewriting the Bitcoin addresses. So for security concerns, if you come to blockchain.info from Tor, they tell you to use the onion address so you get all the fancy properties of entrant encryption and so on and so forth. So as of still today, we know that malicious exit nodes exist and they do rewrite Bitcoin addresses. Don't be alarmed. It's not like all 3,000s. The thing is that we at the Tor project are actively monitoring the network at the exit nodes for this kind of craziness and we need more help from everyone, from the community to find those so we can block them, remove them, so fuck those, fuck those guys. And blockchain took action, we tell them in services, so great. And Facebook set up a hidden service recently as well, an onion address for their website. So the first thing many of you might be thinking is, wait a minute, I don't understand, Facebook is a website on the internet, why do they need a hidden service, why do they need an onion address? So the first answer is they worry about users in interesting countries. Say you've got a Facebook user in Turkey or Tunisia or something like that and they try to go to Facebook and the local DNS server lies to them and sends them somewhere else or Turkish telecom which is a certificate authority that everybody trusts ends up pretending to be Facebook. You man in the middle of them, now there are certificate pinning and other challenges like that and maybe those are good starts but wouldn't it be cool just to skip the whole certificate authority infrastructure and say here's an address where if you go to this in your Tor browser you don't have to worry about BGP hijacking, you don't have to worry about certificate authorities, you don't have to worry about DNS, it's all inside the Tor network and it takes care of the security properties I talked about before. So that's a really cool way that they can switch. I was talking to one of the Facebook people earlier, he doesn't want me to tell the number of users who are using Facebook over Tor but it's many hundreds of thousands, it's a shockingly high number of users. So wouldn't it be cool if we can switch many of those users from connecting to facebook.com over Tor to connecting to Facebook's onion address and then reduce the load on the exit relays so that it's faster and easier and scales better for the people connecting to websites that aren't onion addresses. So I was talking, I was thinking about this at the very beginning and I was thinking wait a minute I don't get it, Facebook has an onion address but they have a real address, why do we need the other one? And then I was thinking back, so you remember ten years ago when people were running websites and the administrator on the website said I don't need to offer HTTPS for my website because my users and then they had some bullshit excuse about how their users didn't need security or didn't need encryption or something like that. And now ten years later we all think that people saying I don't need HTTPS for my website, we think they're greedy and short-sighted and selfish and they're not thinking about their users. I think the onion service thing is exactly the same thing. Right now there are plenty of people saying I already have HTTPS. I don't need an onion address for my website because my users and then they have some lame explanation. So hopefully in a couple of years it will be self evident to everybody that users should be the ones to choose what sort of security properties they want. It shouldn't be about what the website thinks the users should have. I should have the choice when I'm going to Facebook, do I go to the HTTP version? Do I go to the HTTPS version? Do I go to the onion version? It should be up to me to decide what my situation is and get the security properties that I want. The other challenge here, I was talking to some researchers a while ago who said I found a copy of Facebook on the dark web. And I was thinking, wait a minute, you didn't find a copy of Facebook on the dark web. There's a mechanism for securely getting to the website called Facebook. And it's called onion services. That there's no separate dark web, it's about transport encryption. It's about a way of reaching the destination more safely. One of the other really cool things, Facebook didn't just set up an onion address. They got an HTTPS certificate for their onion address. They got an EV cert, the kind that shows you the green little bar that says this is Facebook for their onion address. They went to Digi-Cert and Digi-Cert gave them an SSL certificate for their onion address so now you can get both of them at once, which is an amazing new step that we hadn't even been thinking about at the time. So what does this give them? Why is this valuable? One of them is on the browser side, when you're going to an HTTPS URL, the browser knows to treat those cookies better and to not leak certain things. And there are all sorts of security and privacy improvements that browsers do when you're going there. And we don't want to teach the browser that if it's HTTPS or dot onion then be safe. The other nice thing on the server side, Facebook didn't have to change anything. This is another way of reaching the Facebook server, that's all there is to it. And then another cool thing, it turns out that the only way to get a wild card EV certificate is for an onion domain. It's actually written into the certificate authority world that there's a grand exception for onion addresses. You can't get a wild card EV cert unless it's for an onion address. So this is super-duper endorsement of onion services from the certificate authority people. But let's take a step even farther. Wouldn't it be cool if we take the Let's Encrypt project and they bundle a tour client in with each web server that's offering the Let's Encrypt system. So every time you sign up for Let's Encrypt, you also click the button saying, and I want an onion address for my website. And they automatically, in the same certificate, you get one for riseup.net. And as an alternate name, it's blah, blah, blah, dot onion. It's in the same certificate. So users can go to your website directly or they can go there over the onion address. And either way, you provide the SSL certificate that keeps everybody safe. Wouldn't it be cool if every time somebody signs up for Let's Encrypt, they get an onion address for free for their website so that everybody can choose how they want to reach that website? Now there are a few problems with that. One of the big ones is we want some way of binding the riseup.net address to the onion address so that when I go to riseup.net, I know that I'm going to the correct onion address. So we need some way to vouch for them and connect them through signatures or something. It can be done, but somebody needs to work out the details. The other policy barrier is right now, the certificate authority people say you cannot get an onion address for a DV search, the normal kind of search. You can only get it for an EV search. And Alec over here is leading the charge to convince them that that makes no sense. So hopefully in the next couple of years, with all of your help, they will realize that onion addresses are just like all the other addresses in the world. Which leads to another really cool feature from this year. We got IETF to publicly specify in a real RFC that the dot onion domain is a special case, and they're not going to give it out in any other way. So yeah, so the first effect here is that we have actual approval of onion services from the IETF and other standards committees. But the second effect, which is a second order effect, is now we can go to the browsers and the DNS resolvers and say whenever you see an onion resolve, cut it right there because you know that it's not going into tour and you know that it shouldn't go out onto the network. So now when you're in your normal internet explorer and you accidentally click on an onion address, Internet Explorer knows that that's a local address that shouldn't go out onto the network. So we can keep people safer in ordinary browsers that otherwise wouldn't even care that we exist. Okay, so far we've been talking about websites and hidden services, but this is not all that hidden services can do. Basically, you can do any sort of TCP thing you want to do over hidden services. We're going to show you a few examples of third-party applications that have been developed for hidden services that do various interesting things. First of all, onion share is a file transfer application where you basically download this thing and then you feed it a file and then it exposes a HTTP server that basically hosts your file, an onion address that hosts your file and you can give that URL, you can feed up there to your friend and they can just put it on their tour browser and download the file easily. It's quite convenient, nicely made, and I think various organizations like the Intercept and stuff are using it to transfer files internally and it works fine so far as far as we know. Then there are various hidden services are quite good for doing messaging because basically both sides are anonymous and this gives a nice twist when you talk to some person. And one way to do so is Ricochet, which is like an application that allows you to talk one-to-one to other people. It's decentralized because it works over hidden services. That's actually quite useful because, for example, like a few months ago, the Jabber CCC server got shut down for a few days and you couldn't talk to anyone basically but if you used Ricochet, you were fine because they can shut down the CCC server but they probably can't shut down the whole tour network so easily. It also has a nice slick UI which is quite refreshing if you're used to the usual UI of the open source world. And anyway, you can download it from that web server there. And then there is Pond, which is a more experimental of unguarded messaging application which is basically a mix between messaging and mixed nets. It basically uses like a server which delays your messages and stuff, which makes it much harder for a network adversary to know when you're sending or receiving messages because you also send chaff and the fake traffic and stuff. It's super experimental. The author doesn't even want us to really endorse it but information is free and you can visit that website to learn more about it. So there's also, for many years now, plenty of services and tools that exist. George just showed us some tools but now there's services like Jabber, SMTP and IMAP from the RiseUp guys but not only RiseUp but a system lie, Artistici and Calix Institute for Jabbers. And it's more and more and more Jabber server right now that are federating through the onions for server to server and also client to server. And this has been around for a long time and it serves many, many users. I think RiseUp has more than 30,000 users on their Jabbers. Another neat thing that happened is very recently is that Debian created a package to repository and now you can use an onion address to just update your Debian system. And you use this amazing package which is APT Tor Transport and up you can update everything to an onion address. It will date it automatically. But then there's also much more that happened recently. Also the GPG server exists as an onion address. So you can update your GPGs, your GPG key and download the signature and so on and so forth which in a way hides from global servers because we know they exist on your social graph because, well, you're into an encrypted channel. Of course they can go to GPG server, that's true. But still at least on the wire, it's hidden. Very nice. Now, Doc.Go, of course, they have Jabbers and they also have hidden service and I talked to the Doc.Go people a few months ago maybe, I don't remember. But the point is they have many, many, many users coming through their onion address. The part they also. So the point of all this is that with Facebook and a blockchain and all those we've seen and we actually know that several Alexa 500 top websites are actually currently deploying on your addresses and the point there is between the TorNet or the onion space and the open internet, we want, if all sites are on both sides, well, it becomes one side. It's just different ways of accessing the information. So please, please, please go to your companies, go to your organization, deploy your new addresses and make them public. Help us have much more. Let me, before I get to the next one, re-emphasize the point that George was making about Ricochet. So Ricochet is an alternate chat program where every user is their own onion address. Every user is their own onion service and you talk from one onion service to the other onion service. You don't have to know where the person is or necessarily even who the person is and there's no middle. There's no central point to go and learn all the accounts and who's friends with who and so on. There's nothing to break into in the middle where you can spy on everybody. Everything is decentralized. Everybody is their own onion address. So I think that's a key point as an alternate chat paradigm where, hopefully, we can switch away from the centralization model. OK. So on to phase two, a brief diversion. We've been talking to a bunch of researchers over the past few years about they want to do research on tour to study how many users there are or how many people go to Facebook or all sorts of other research questions. And sometimes they do it in dangerous ways or inappropriate ways. So we've been working on guidelines to help people who want to do it safely actually be able to not harm people or minimize the harm. So here are some of the guidelines. First one is try to attack your own traffic, try to attack yourself. So if you have a question and you need to do it on the real tour network, you should be the one to generate your traffic and then try to attack that. You shouldn't just pick an arbitrary user and attack them because who knows? That's a person in Syria who needs help or a person in Germany who's trying to get out from oppression and so on. Another approach, only collect data that you're willing to publish to the world. So too many researchers say, well, I'm going to learn all of this interesting stuff and I'm going to write it down on my hard drive and I'll keep it very safe. Nobody will break in. That approach fails every time somebody breaks in, you lose the data, you forget about it. So the ethical way to do this is only collect stuff that you're willing to make public, only collect stuff that's safe to make public. And then the other piece, that's part of what we were talking about there. Don't collect data that you don't need. So figure out what your research question is, figure out the minimum that you can collect to answer that question. For example, if I want to know how many people connect to Facebook, I should not collect every destination that everybody goes to and then afterwards count up how many of them were Facebook. I should have a counter that says Facebook, increment, and then at the end it outputs a number and that's the only thing that I need to know in that case. So limit the granularity of data. If you're counting how many users are connecting from different countries and there are very few users coming from Mauritania, consider rounding that down to zero so that you don't accidentally harm the five people in Mauritania who are using it today. So an approach to do this is figure out what you're trying to learn, describe the benefits to the world of learning that, describe the risks to people around the world in tor of the approach that you're taking, and then argue that the benefits are outweighing the risks. And one of the key ways of looking at this is if you're collecting something interesting, some interesting data set, think about whether there could be somebody else somewhere out there in the world who has some other data set, and when you combine their data set with yours, somebody learns something new, somebody gets harmed. If you can imagine any other data set that when it's combined with yours harms people, then you need to think harder about that. So, and then the last point, use a test network when possible, there's a tool called Chutney, there's a tool called Shadow where you can run your own internal Tor network on one computer, and if you can do your research that way, it's even better. So, those are great guidelines, sounds good, we need to encourage more people to do them. And to be fair, this is not going to stop bad people from doing bad things, but if you want to do research responsibly and ethically without harming core users, then we need to help everybody learn what the guidelines are to do it more safely. So here's an example of a tricky edge case where we really want to think harder about these things. One of them is there are people out there who want to build a list of every onion address that they can find. So, you can learn about that by going to Google and doing a Google search on .onion and they give you some addresses, that's okay, that seems reasonable, it's a public data set, okay fine. There's a more complicated one where your verisign and you run some of the DNS root servers and you spy on the DNS queries of the whole internet and anybody who accidentally sends a .onion DNS query to your root server, you write it down. So now you learn all the side channel accidentally leaked addresses. Is that, does that follow our guidelines? Is that okay? Is that ethical? It's kind of complicated, but I don't know a way to stop it and they already have the data set, so okay fine. Now a more complicated one, what if you're Comcast and you spy on all of your users to find out what their DNS queries are to learn about accidental leakage there? Again, I'm gonna say it's complicated but it's probably fine, they're already seeing it. There's nothing we Tor can do to change our protocol to make people accidentally leak these things. But then option four, what if you want to learn a bunch of onion addresses? So you run new relays in the Tor network and you sign them up and they get into a position where they can learn about onion addresses that are being published and then you make a list internally, so that's actually not cool because it's part of the Tor protocol that people providing onion addresses don't expect those to become public and we'll talk later about ways that we have for being able to fix this. So if it's a protocol problem that we know how to fix and it's inside Tor and you're misbehaving as a relay, then that's not cool. So this is an example where it's sort of hard to reason through where we should draw the line and I'd love to chat more with you all after that about where the line should be. And that leads to an example of some research that was done last year by, we think, some folks at CMU who attacked the Tor network and as far as I can tell collected a data set and they collected more than they needed to answer their research questions. They didn't do minimization. They didn't attack only their own traffic. They didn't use a test network. They basically violated every one of the guidelines from two slides ago. So that's sort of a sad story and that leads to the next question. Should we have some sort of Tor ethics review board? Wouldn't it be cool if as a researcher you write up what you're trying to learn and why it's safe and how you're gonna do it and you show that to other professors who help you decide whether you're right and then we go to the academic review journals and conferences and we get them to expect in your research paper a little section on why this is responsible research and at that point it's expected that you have thought through that and anybody who writes a paper without that section everybody knows that they haven't thought it through as much as they should. Wouldn't that be a cool future world where research is done more responsibly around Tor and around security more generally? Okay, so there are a couple of problems in Tor onion service security right now. I'm gonna zip through them briefly so we can actually get to talk about them in more detail. The first one is the onion identity keys are RSA 1024 bit. So that is too short. We need to switch to ECC. Another one is you the adversary can run relays and choose your identity key so that you end up in the right place in the network in order to target, sensor, surveil, whatever certain onion addresses and we'll talk more about that also. Another one, I talked about that a few slides ago, you can run relays in order to learn about new onion addresses and we've got some fixes for that. So those are three that are onion address specific, onion service specific that we can solve and then there are three issues that are much more broad. One of them is bad guys can run hundreds of relays and we need to learn how to notice that and protect against it. Another one is you can run relays to learn more about the path selection that clients are gonna do and then there's website fingerprinting. All of those are separate talks. I wanted to mention them here. Happy to talk about them later but we don't have time to get into them in detail. Okay, phase three, how do Tor hidden services, Tor onion services work right now? Just to give you some background so that when we talk about the design improvements you have a handle on what's going on. So we've got Alice over here. She wants to visit some hidden service Bob. The first step is Bob generates a key and he establishes three introduction points, three circuits into the Tor network and then he publishes to the big database in the sky, hi this is my key and these are my three introduction points and at that point, Alice somehow learns his onion address and she goes to the database and pulls down the descriptor that has his key and the three introduction points and in parallel to that, she connects to the two, she picks her own rendezvous point and she builds a Tor circuit there. So at this point, Bob has three introduction points open in the Tor network and Alice has one rendezvous point open in the Tor network and at that point, Alice connects to one of the introduction points and says, hey, I wanna connect to you and I'm waiting over here. This is the address for my rendezvous point. If you wanna talk back to me, I'm waiting right here and then at that point, Bob, if he wants to, makes a connection to the rendezvous point so now Alice has a connection to the rendezvous point and Bob has a connection to the rendezvous point and at that point, they do the crypto handshake so that they get end to end encryption and then as the last step, they're able to send traffic over that circuit where Alice has three hops and Bob has three hops and they're able to provide security from that point. So that's a very brief summary of how the handshake works in Hidden Service Land and then let me, so in the previous slide, I was talking about this database in the sky. Once upon a time, that was just three computers. I ran two of them. Another directory authority operator ran the third and then we switched to distributing that over the entire Tor network so there are 8,000 relays and so imagine the hash of each relay's identity key on this hash ring. There are six relays at any given point that are responsible for knowing where a given onion service is so when I'm running my own onion service, I compute which six relays they are and I publish my descriptor to it and when I'm the client and I wanna go there, I compute which six relays they are and I go to any one of them and I can fetch the descriptor. So the way that we actually generate the predictable set of which relays there are is this hash function up in the top. So you look at the onion address, you look at what day it is, the time period and other things that are pretty static so that's how both sides can compute which relays they should go to when they're publishing or fetching a descriptor. Okay, so back to the security issues again. So a few years ago, like two, three years ago, we started looking into hidden services and enumerating the various problems various people wrote papers about some open issues of security and stuff. So I mean, like on 2013, we wrote the first proposal called Next Generation Hidden Services which basically details various ways for improving security, better crypto, blah, blah, blah, blah, blah, blah. This happened like two years ago and we still have not been, we haven't started heavily developing because of the lack of basically developers since Hidden Services have been largely a volunteer driven project since like a year ago or so. So everything was done on our spare time basically. But we've been writing proposals, we've been active anyway. So we're going to start looking over the various security issues and the ways to fix them, let's say. The first one is called, we call it HSD or Predictability and it touches the subject that Roger mentioned, the database in the sky which is basically that when a hidden service every time has six hidden service directories, six relays of the network being responsible for it. So every day each hidden service has six relays responsible for it and it chooses it using this weird hash formula there which if you can see, it's deterministic. So all of them are static apart from time period which rotates every day but the problem is that because it's deterministic you can basically plug in the onion address you want and the time period in the future and you can basically predict the result of that function in like two months from now. So you can basically know which relays will be responsible for a hidden service in two months and if you're a bad guy, maybe you will go and inject yourself to that place and you will become the HSD of a hidden service and then you can do, you can like monitor its activity or you can do DOS attacks. So this is not something we like and we will attempt to fix it. Our idea for fixing it is that we will have to make it from deterministic, we will have to turn it into probabilistic thing and we do this by adding a random value in it and this random value is basically a fresh random value that the network is going to be generating every day. So how we do this is we use this nine directory authorities from the network, they're like these nine computers, they're hard-coded in the source code and they're considered semi-trusted and basically we wrote a protocol that all these nine directory authorities do a little dance and in the end of the day they have a fresh random value every day. It's not something new, it's like it uses like a commit and reveal protocol which is some way to do some sort of distributed random number generation and then every day they make this random value, they put it in the consensus and then hidden services and hidden service users take the random value for the consensus, plug it into that formula and they use it and since this is supposedly secure protocol I shouldn't be able to predict what the random value is going to be in two months. Hence I cannot go and inject myself in that position in the database basically and this is the way we fix this problem. Right, so continuing now on the next generation in services, one of the first, the key thing is better crypto. Right now we have RSE 1024 and SHA-1 which are considered completely bad to use and we're gonna use of course this fancy man there work, Daniel. So it's basically ED25519 for crypto and signing and of course using SHA-256. Right now in Tor we are experimenting in implementation upstream of SHA-3 although apparently we're not sure if SHA-256 or SHA-3 will be used but right now SHA-256 is a contender because it goes way faster than SHA-3 but SHA-3 has more things, still pending but for now elliptic curve. So what to take of that is next generation in services which we are actively working on right now will drop all dead crypto. One of the big changes that's coming up is the onion addresses. On top you have the currently onion address and it's gonna move to 52 characters, basically your public key. This is maybe for you from you guys that consider painful and from us is extremely painful to enter this address or just to type in an address like that. So open proposal right now or I think there's either an email thread on our mailing list on, coming up with some more fancy way to remember an onion address that size. So I have words, remembering words that just mash in together and create that address. So yeah. Now, as the Indian service evolves one of the thing we really wanna do is make them faster. The big difference between Indian services in a network and a normal tour circuit in the network is that normal tour circuits usually have three ops then Indian services you have three ops from the client and three ops from the service thus you have six ops. So of course much more time to go through all the relays than the normal circuit. Now we have this proposal going on which is the Rendezvous single onion services and the point is you're gonna do the dance, the introduction, the Rendezvous and then once you go to the Rendezvous instead of the service going three ops you're gonna go one up to the service. So in here we have this artist wanting to update her Debian machine, let's say that. And the Debian server doesn't care really much about anonymity because we know where the Debian servers are and that's fine. Does clients still have anonymity with the three ops then the service doesn't care? So only one up and then it goes way faster. So that's something we hopefully are gonna deploy soon. Now the second one is a single onion service. It's roughly the same. So we have this chef here wanting to go to his third trade website or whatever. And the difference here is that we are going to skip completely the introduction in Rendezvous a dance and you're gonna do a three ops so it goes to a Rendezvous point where the Debian service will, well let's call it the node, introduction to TD and an introduction point which is the yellow line and then the client will go to that introduction point and instead of having this current dance the client extends to the service and now we have a three opting no prior work being done for introduction Rendezvous and it goes way faster. Again, those two here and there are optimization for service that do not care about anonymity and there are plenty of use cases for that. Facebook for instance, or Debian repository and so on. Am I still on? Great, Facebook and Debian are really excited about having one of these options so that they can have all of their users reach their service with all the cool security properties we talked about, but also a lot faster and more scalable than the current design. Precisely. So one of the very cool thing we did this summer was the tour summer of privacy. We got some people in which we can consider interns or students, whatever and one of the project that came out of this cool person that is Donica created Onion Balance. So it's the way of load balancing hidden services. So as you create an hidden services with the top key then you copy that key to multiple machines so all those servers will start creating a descriptor and basically the descriptor if you can remember is how to reach me and we're gonna cherry pick introduction point for me each and create a master descriptor that you can see in the picture and that master descriptor is what clients will use. Does your load balance in the network depending on introduction points and the instance and this is great and we actually know that Facebook will actively start beta testing these things so we can have load balancing and CDNs and much more easier for onion addresses. So just before I give these slides to Roger the next generation of onion services is something that has been around for two years now and now we're gonna start working in 2016 actively and almost with four full-time developers on that. It's still not enough, we need resources because we need to get away from our funding that restrict us from not working on any services which we have a bit now so resources is very, very important so we can get these things are extremely important and in the next year we hope to get this thing done. Great, so there are a couple of important takeaways from what we've been describing to you today. One big one is there are a lot of different types of onion services out there. There are a lot more than people think. Everybody looks at hidden services and says, oh, they're for websites that the government hates or something like that. But there are examples like Ricochet, like Facebook, like Global Leaks, like SecureDrop. All of these different examples are cool things you can do with better security properties for your communication. So it's not about hiding where the website is, it's about getting more secure ways of reaching websites and other services around the world. So another key point, this is still a tiny fraction of the overall Tor network. We have millions of people using Tor every day and something like 5% of the traffic through the Tor network is hidden service or onion service related. So it was 3% last year, it's 5% now, it's going up, sounds good, but it's still a tiny fraction and maybe that's good because when you're using an onion service right now you put double load on the Tor network because both sides add their own circuit. Whereas if we switch to some of these designs that David was talking about, then it will be much more scalable and much more efficient and it would be really cool to have Amazon and Facebook and Twitter and Wikipedia and so on, all allowing people to get more security while using Tor while protecting places like Facebook from learning where they are today. Another key point, we've got all these cool designs that we touched on briefly, we'd be happy to tell you more about them after the talk and then the last point, you run a cool service out there, please set up an onion version of it, please set up an onion address for your cool service so that the typical average onion service in the world becomes a totally normal website or other service that totally ordinary people go to and that's how we will mainstream this thing and take over the world. And then as a final point, we are in the middle of our first ever donations campaign. We're actually trying to grow a base of people who want to support Tor in the same way that EFF has done. So it would be wonderful. I don't wanna throw away all of our government funders, at least not right now, but I would like to get to the point where we have other options, more sustainability and we don't have to look at each new funding proposal and wonder if we have to unfund people if we don't get it. So I'd love to have much more diversity in the type of people who are helping Tor to exist and thrive and help save the world. So please consider helping. Thanks a lot for this awesome talk. We have six minutes left for questions and please line up at the microphones, one, two, three, four, five, and six down here. And while you are doing that, we would like to hear a question from the internet. Thank you. I have a bunch of questions regarding compromised onion addresses. Do we have a kind of evil twin problem and what can I do if my onion address is compromised? And there are widespread services on the CharNet, like Amazon. How do I know which one is the official service? So the first question of if your onion key gets stolen or something like that, that's the same as the SSL problem. How do you keep your certificate for your web server safe? The answer is you should keep it safe just like you keep everything else safe. And if somebody gets the key for your onion address, sucks to be you. Don't let them do that. For the second question, how do you know that a given onion address is Amazon's? That ties into the certificate authority, the HTTPS, the EV cert discussion that we talked about where we need to somehow bind in Amazon's SSL certificate the fact that it's Amazon and this is their alternate onion address. We need to put those in the same certificate so that everybody knows if you're getting one, then you know it's really Amazon. Thank you. I would like to hear the question from microphone one and remember to keep it short and concise. Again, the address issue, switching from 16 to 52 characters is nice, but if we have to change the algorithm again, would it be nice to have like a prefix to determine the algorithm for the address? Yes, we actually have a couple of extra bits in that 52 bytes and we could use them for versioning or all sorts of things. And there are some examples of that in the proposals. I don't think we've fixed on any answer yet, so we'd love to have your help. Thank you. Please, microphone number three. Hey, you gave us a couple of examples from Facebook and I was just wondering if there's any sort of affiliation between Facebook and Tor or Facebook just happens to be really keen on offering their services in less democratic jurisdictions. There's a nice guy named Alec up here who on his own thought of making Facebook more secure using Tor and he went and did it and then we realized that he was right so we've been trying to help him ever since. Thanks a lot. Microphone number four. You said that you want more and more people to use to run hidden services. My question for this is, are there any guidelines on how to do that, how to, examples, how to do it with specific services? Because from what I've seen, because I tried doing this for some of the services I run, it's not, it's painful most of the time. And with the increase of the addresses right now, the size of the addresses is going to become more and more painful. And one of the things that I'd love to see for this, for example, a DNS record type, that's the onion that you can add for your normal DNS records so people can just look into that and choose between A, A, A, A and onion to connect to. Yeah, for that last one, for the DNS side, if we have DNS sec, thumbs up. If we don't have DNS sec, I don't want to have that terrible security link as one of the first steps. I don't want to trust the local DNS resolver to tell me I can go somewhere else and then after that, if I get the right address, I'm safe, that sounds terrible. So on how to set up hidden services correctly, I think RiseUp recently published some sort of guidelines with various ways you can tweak it and make it more secure. I think there are also some on the Torwiki, but in general you're right that there are various ways you can mess up this thing and it's not super easy for anyone here to set up a hidden service right now. And hopefully in the future, we will be able to have an easier way for people to set up hidden services, maybe provide a bundle that you double click and it spawns up a blog or a docker image. I don't know, it's still one of the things we really need to look into. It would be really cool to have a server version of Tails that has all of this built in with a like Python web server that's hard to break into and automatically configured safely. That would be something that would make a lot of people able to do this more conveniently and not screw up when they're doing it. Okay, so we have a bit of less than one minute left so I would say last question and let's say microphone number three for that. Hello, I have two small questions. No, one. One, okay. So I noticed you have some semi-trust assumptions for the random number generation for your relays. Did you consider or do you think there's some merit in using the Bitcoin blockchain to generate randomness? We consider using the Bitcoin blockchain, the NIST beacon, all these things but they're not like there are various engineering issues. Like to use the blockchain thing, you need to have to verify the miracle trees. These need to be code on the Torcode base. You also depend on Bitcoin which is a system quite powerful to be honest but you probably don't want to depend on outside systems. We really consider it though. Thank you. Thanks a lot for this Q&A. I think you will stick around and be available for another question and answer more personal after the next upcoming talk which is state of the onion in 15 minutes.