 Thank you, thank you. Thanks for being here shortly after lunch or during lunch or I don't know what's the exact timing of lunch during DefCon, it's my first time. So this talk, everything about it started during an internship I had at Cloudflare with Nick Sullivan who's sitting there over the summer. Essentially I joined a week or two after Cloudflare launched this consumer DNS service, 1111, you may have heard about it, it was a small thing. And one day Nick walks in and says okay we don't keep any logs of users and anything that we happen to have any sort of IP information we delete after 24 hours but what if we moved that over tour so we didn't have any information about the user requests. So that started the whole chain of events that you know we started looking at how do we do this over tour, starting an onion service to serve as our DNS over HTTPS server and ran into some problems. One of them which I imagine if you run any onion services you might have noticed is if you want to add HTTPS to your onion service you have the option of paying a lot for extended valuation or using your own certificate or 30 which is not a good idea generally. So here's an alternative that I sort of connect back to an older idea which is opportunistic encryption. So opportunistic encryption is not just one idea but in general across many different protocols. As far back as start TLS and very recent as upgrading HTTPS over HTTPS and things like that. The idea is you can start the connection normally unencrypted but there's some sort of tag, some sort of you know communication and if the server and client both supported they can upgrade their connection over a more secure format. So the motto on the RFC that announced opportunistic encryption was some protection most of the time. On the other hand mine is opportunistic onions more protection some of the time. And here's the hide works. Okay so I'm going to start with a short crash course of how tour works. Of course I'm not going to include all the details but it'll be the gist of it hopefully. Okay so great nothing is out of the screen. So on that side we have a client laptop and this side we have the origin web server and the middle we have the tour cloud. Well we have the tour network. In the middle we have a bunch of different nodes some of them are relay nodes exit nodes various kinds of parties in the tour network. We also have the hidden service directory which is sort of in between inside and out. The address to those hidden service directories are fixed and the first time the client is trying to make some kind of communication to get information about the rest of the nodes has to do some out of tour network communication. Okay so the first step I numbered them the zero step is getting some information from the hidden service directory. Then via some process the client establishes a circuit to an exit node somewhere in the world and this circuit passes through a guard node that may or may not be fixed and a relay node. And after that the exit node essentially requests whatever final destination final website you wanted from the internet and sends that back to you over the tour network. So but before that the exit node has to also make a DNS inquiry if the request was a domain name not an IP address and then make the request the origin and have sort of color coded this the green ones are encrypted the orange ones may or may not be encrypted because if your origin supports HTTPS if you're you know going to say gmail.com that supports HTTPS over tour then you usually don't have any problem. But if it doesn't if the destination doesn't support HTTPS or if the first request is not HTTPS then that might introduce some problems. Okay. So what is where does the idea of onions come from? The idea is take this image that we have this is sort of the way I intuitively think about it that look at the exit node cut it down there and mirror everything on the left to the right. So essentially that RP in the middle the rendezvous point you can think of it as an exit node on both sides that's not really an accurate description but it does the job of you start with the client starts with connecting to a guard node really know the rendezvous point that via some a number of steps establishes a connection with an onion service and the onion service note that in this case is inside the tour network. So no communication is going outside of the tour network on this side versus here this communication number five and four we're going out of tour network here everything is inside. Okay. So what can we do with this? First of all as I said one problem is that if you want to have an HTTPS certificate for an onion service if you have any if you've seen any onion services the addresses look like a 56 character randomly looking 56 character domain name dot onion or the older HSV2 which is shorter but still a semi random string of characters dot onion. So one question is how do you remember this address? Some people like Facebook for instance tried to try to essentially mine a nice looking address. So they they they generated Facebook w w w core eye or something like that dot onion. But if if in general you know if anybody wanted to do that first they would have the problem of many people don't have that much computing power and two even if you do if you want to have an HTTPS certificate for your upside. Again you have to go to certificate authorities and you have to pay for extended valuation which costs a lot at least a few hundred dollars a year I think. And I I personally think it's too much. So the alternative is is this. So imagine that the origin was partially in the tour network and partially out. Okay so the first the very first connection the very first request that you make still goes through the the the same steps through a guard relay sorry through a guard a relay exit note requesting the DNS information making connection to the origin so far everything is the same then the origin responds with an alt service header. What is an alt service header? An alt service header is a new HTTP well not not so new but it's a recent HTTP header that essentially tells the website that if you want to communicate with this host you can also use this other host that you know the origin tells the client that this is this has the same credentials this is has the same resources everything the same. There's a small difference though this is not to be confused with you know the old like Apache rewrite rules. This is different because Apache rewrite rules you could you could have for instance for a certain for certain pages you could have a rewrite rule or something like this. This is for the whole for the whole host. So for instance if I you know if I own I don't know example dot com and I say you can also reach example dot com via you know a certain IP address then after certain after a number of steps after a number of steps the browser makes sure that the two host names are you know can serve the same website they have the same HTTPS certificate and then instead of connecting to the to example dot com if for instance the network connection to the IP address is faster can make the connection to the IP address. So what we do is we send an old service header and in it we put the address for the onion service. And so the point here is that you're making a connection to example dot com and you get a response that says you can also connect to me via this long string of characters dot onion. This is also another address for me. What the browser does the browser sends a request to that establishes a circuit with that onion service so here's where I go here. After getting the old service the client establishes a circuit to the onion service and verifies that the onion service can serve the same exact certificate the same exact HTTPS certificate as the origin in the very first request. So the important point here is that the certificate does not have to be does not have to have the onion address in it. It can only have it can it only needs to have the you know example dot com. Does that make sense? So the main point that you needed extended valuation was that dot onion you know certificate authorities don't like giving free certificates to dot onions but with for instance let's encrypt you can get a free certificate for your website and using this system you can use the same exact certificate to establish well to have an onion service. Okay so any questions so far before I go into benefits and why we did this? Right so yes so you notice here that from this picture to this picture the length of the circuit from the client to the onion service is shorter. So the point is that this system is for when the content provider the onion service wants to remain hidden but if you know we are talking about a website that already has a domain name that already has a publicly accessible IP address you know there's nothing there's nothing to prevent. The point at this point is to enable people from the Tor network to connect to it instead of going through an exit node just connect directly all inside the Tor network right so there is no privacy or anonymity cost for the web server because you know the location was already public to begin with. But that's a good point thank you thank you for the question. Okay so let's look at some of the benefits. First of all this is going to reduce the load on the exit nodes because only the very first request has to go through an exit node. After that the browser can you know for a certain amount of time perhaps remember that this host name can be accessed by this onion service and only make connections to the onion service. Another is that the attack surface from the exit node is reduced because instead of every request going through an exit node only the very first one does that. And lastly because of that we think this improves privacy of the users for instance you know there are some papers on correlation attacks on the Tor network if someone could observe network traffic coming out of users client for instance at ISP level and coming into the onion service. For instance if you were running an onion service on you know Google cloud and your internet was or your users internet was via Google fiber then Google would have information on both sides of the Tor network going in through Google fiber and going out to onion service and at that point Google could have some you know information via some correlation attacks and this would hopefully prevent it because only one request is going through and you can't do any sort of correlation of how much you know how much the size of the content is or anything like that. Okay but specifically why was Cloudflare interested in this? This is because we can because of the system instead of so from the server's point of view from Cloudflare's point of view instead of all the requests coming from the IP address of the exit node we see specific circuits we can't you know identify who the user is but we can distinguish them we can say that this is this is a circuit for the first user this is a circuit for the second user and then they're separate separate users. I should note that users can have multiple circuits and and we can't we have no way of linking those so it doesn't you know cost any anonymity for the user but it gives us the advantage of you know having more fine grained late race limiting which means if if you know an exit node if there are a lot of DDoS attacks or something like that coming from an exit node we don't have to ban all of it and ban you know all the or you know capture all the good people using that exit node we can look at the circuits individually and say oh this circuit is doing something you know funky or too many requests or they look like some sort of you know SQL attack or something like that. We will capture that but anyone else can can carry through normally. So this is going to hopefully reduce capture friction for our tour users. Let's see and I should mention many thanks are owed to Mozilla people at Cloudflare of course and the tour project we had a meeting about a couple of months ago to discuss you know how could we make this actually usable and part of it was having the tour browser the new version of the tour browser which hopefully should be coming out soon be able to use this old service header and also use HTTP which was a requirement for this system to work. And I should mention if you want to test this feel free to send an email to onion dash beta at cloudflare.com. This is also okay for free customers you don't have to be a paid customer and also on the on the client side if you want to test it you would have to go to the config and just change two things namely enable alt service and enable HTTP to okay any questions have one more thing to oh yes. If you have questions we're going to bring questions up to the mic just so you saw a few minutes so you could. Sure so one last thing that I promised in the description to offer was a catty catty is a HTTP server plug in to enable this this is currently on github if you find my github account I should perhaps put a link here it is called catty dash opportunistic onion or sorry catty dash alt onion and also if you send an email to this I'll make sure to publicize it why at that and then hopefully at some point it'll be published on catty's website. Thank you. All right any questions line up to the mic please we got five minutes for questions and after that if the speaker has time you can tag up with them outside. Hi I have two questions first one is what do you think of the implication of bootstrapping this process based on DNS and the second one is yeah how reliable is circuit tracking to identify clients on hidden services? Right so the first question was so we've actually thought about ways of providing you know if you see a request okay we already have a DNS server on an onion service so we were thinking of how can we have you know if a request is coming through this onion service which serves a DNS the client clearly supports Tor so we can might as well send maybe a C name or something like that directly to the address we're still you know we're trying to work out the kinks of it to make sure that you know there's no chance of us the DNS provider or you know maybe not us but whoever is the DNS provider you know giving you a random onion's onion address that's one problem the second one was it about fingerprinting the users? No it is about like to my understanding it's not I didn't know there was a one-to-one mapping between the circuits hidden service builds with these clients and actual clients? Oh this is not a one-to-one correspondence so each individual Tor client can establish multiple circuits in fact the circuits happen all over the time you know the connection you make to the hidden service directory or maybe not that one the connection to each of the relays the rendezvous points all of these are to introduction points for the onion service all of these are circuits and all of the all of them have some sort of internal ID to you know to distinguish them so in a sense between a client and an onion service there can be multiple circuits but the point is that we can ban we can you know challenge each circuit individually instead of instead of just and massive for IP address or something like that. Alright let's give it up for our esteemed speaker. Thank you.