[00:00.700 --> 00:01.500]  All right.
[00:01.880 --> 00:02.780]  Hello, everyone.
[00:03.440 --> 00:06.260]  This is our second talk, so I guess you know us.
[00:07.140 --> 00:10.020]  Today we're going to talk about understanding Tor Onion Services.
[00:10.360 --> 00:14.280]  So just off the bat, Tor Onion Services used to be called hidden services.
[00:14.780 --> 00:21.280]  We changed the name for obvious reasons, especially media likes it when it's hidden services, put bad things in there.
[00:22.180 --> 00:27.400]  So first of all, this talk is going to be much more technical than yesterday.
[00:27.740 --> 00:29.660]  We're going to go deep into hidden services.
[00:30.400 --> 00:33.520]  Attacks, next generation, so on and so forth, but also use cases.
[00:34.440 --> 00:43.140]  First of all, we're going to start with how Tor works, because we didn't do that yesterday, and this is an important part, so we all understand what are different parts of the network.
[00:44.340 --> 00:49.720]  So this slide, you probably saw that diagram many times.
[00:49.840 --> 00:50.500]  EFF has one.
[00:50.780 --> 00:57.800]  So basically, Alice wants to talk to Bob, goes through the network, and then encrypted links are the blue ones.
[00:58.560 --> 01:00.320]  And the first one is the guard.
[01:00.480 --> 01:04.540]  So it's very important that you understand what a guard is, because we're going to talk about guards quite a bit.
[01:05.240 --> 01:06.380]  Guard is the entry node.
[01:06.800 --> 01:10.480]  So you get a guard after a while when your relay is stable enough and fast enough.
[01:11.120 --> 01:13.900]  And then you get this flag so people can start using you.
[01:15.140 --> 01:24.820]  Every client, every hidden services, every component in the network interacts with Tor circuits, use a guard, and will pin the guard for around three months.
[01:25.200 --> 01:27.980]  And our reasons behind that, we won't go into details, you can ask us.
[01:28.360 --> 01:30.880]  But keep in mind, this guard, you have it for a long time.
[01:30.880 --> 01:31.960]  Then you go to a middle.
[01:32.100 --> 01:33.720]  Middle is pretty much any relay.
[01:33.880 --> 01:34.480]  And then exits.
[01:34.900 --> 01:39.420]  So the exits, in this case, this is just a Tor circuit.
[01:39.500 --> 01:43.580]  In case of onion services, you don't have exit, because you don't exit the network.
[01:45.040 --> 01:55.180]  But exits are very special nodes in the network, because traffic gets unencrypted there, and sent into the open interweb, unsecured Internet.
[01:55.180 --> 01:59.120]  So, this is what we call a Tor circuit.
[01:59.380 --> 02:00.340]  Three ops, basically.
[02:02.880 --> 02:07.340]  So, a quick overview of what hidden services are, onion services now.
[02:07.740 --> 02:10.760]  So, basically, one .onion address, 16 character longs.
[02:10.840 --> 02:11.460]  It's base 32.
[02:11.680 --> 02:13.020]  It's pretty easy to understand there.
[02:13.700 --> 02:15.320]  It's a client services side.
[02:15.560 --> 02:16.200]  Both are hidden.
[02:16.380 --> 02:18.300]  So both are anonymous.
[02:19.000 --> 02:23.280]  So it's a very important property, because as a client and as a server, you can protect yourself.
[02:24.080 --> 02:26.520]  Everything stays inside the Tor network.
[02:26.800 --> 02:30.640]  That means that the onion service traffic doesn't go outside...
[02:30.640 --> 02:33.260]  It doesn't go through an exit node, as on the Internet.
[02:33.780 --> 02:35.540]  And all sorts of TCP traffic.
[02:35.840 --> 02:37.460]  Remember, Tor is only TCP.
[02:39.180 --> 02:40.500]  So, a quick history here.
[02:41.200 --> 02:42.720]  Hidden services are quite old.
[02:43.100 --> 02:43.660]  2004.
[02:43.880 --> 02:46.320]  This is the first commit about hidden services.
[02:47.620 --> 02:49.600]  2004 is, what, 12 years ago?
[02:49.820 --> 02:50.860]  So, pretty old.
[02:50.860 --> 02:53.640]  So, we're gonna show you how this has been evolving.
[02:55.060 --> 03:05.180]  First of all, so, in 2014, maybe, beginning of 2015, we started to have statistics to try to measure what's going on in the service world.
[03:06.020 --> 03:07.540]  This was quite a bit of challenge.
[03:07.780 --> 03:12.820]  It took us many months, actually, to come up with a privacy way...
[03:12.820 --> 03:16.880]  A way to collect those statistics in a privacy-oriented way.
[03:17.140 --> 03:20.840]  So, this is the amount of unique .onion addresses that are currently in the network.
[03:21.160 --> 03:22.540]  We don't know what happened in March.
[03:22.700 --> 03:25.460]  Someone, you know, just created half a million of those.
[03:27.300 --> 03:28.940]  And then, it went back.
[03:29.120 --> 03:32.260]  So, right now, we're around 60,000 unique .onion addresses.
[03:32.460 --> 03:35.800]  So, that means unique ways.
[03:35.920 --> 03:36.180]  We don't know.
[03:36.240 --> 03:37.920]  I mean, we don't know if it's clients, servers, or whatever.
[03:37.920 --> 03:39.700]  But, right now, this is the state.
[03:39.900 --> 03:40.880]  And this is the traffic.
[03:41.320 --> 03:43.220]  So, those are the two statistics we have.
[03:43.420 --> 03:44.880]  The number of onions and the traffic.
[03:46.940 --> 03:48.600]  So, yeah, this... I don't know.
[03:48.740 --> 03:50.240]  We absolutely don't know what happened.
[03:50.460 --> 03:52.300]  Again, it dropped.
[03:52.500 --> 03:55.380]  Maybe, like, someone leaked a huge thing and it stopped.
[03:55.500 --> 03:55.940]  We don't know.
[03:57.400 --> 04:10.640]  But, overall, what it gave us is a way to show that onion services are still very, very low amount of traffic of the overall Tor network.
[04:10.860 --> 04:17.760]  So, every client that connects to an onion services, it's around 4% of the overall traffic in the Tor network.
[04:17.760 --> 04:28.600]  So, when you're in the media or whatever, governments or propaganda that tors only bad things in the dark web, well, remember that it's only 4% of this overall traffic.
[04:28.780 --> 04:31.400]  And in this 4%, it's also a small percentage.
[04:33.080 --> 04:35.720]  So, now, we're gonna go into properties and use cases.
[04:36.060 --> 04:36.820]  It's pretty nice.
[04:38.360 --> 04:38.840]  All right.
[04:39.760 --> 04:45.780]  So, hidden services or onion services have a lot of interesting properties.
[04:45.780 --> 04:48.100]  First of all, they are self-authenticated.
[04:48.740 --> 04:50.160]  They are end-to-end encrypted.
[04:50.380 --> 05:00.740]  Self-authenticated in a way that, like, if two... a server and a client are talking to each other, they don't know where... like, the server doesn't know where the client is and the client doesn't know where the server is.
[05:00.880 --> 05:07.180]  They just know each other and they can authenticate with each other with different layers of encryption.
[05:08.040 --> 05:13.500]  But they know, like, who that person is, but they don't know where that is and what's the IP address.
[05:14.240 --> 05:15.640]  They are end-to-end encrypted.
[05:15.920 --> 05:23.240]  There is no need for CA mafia, basically, to get a certificate for whatever.
[05:23.580 --> 05:35.080]  And you can pretty much do a lot of isolation when you run an Onion service in a way that you can basically run a server somewhere.
[05:35.280 --> 05:43.000]  It could be on a Raspberry Pi in your apartment, and it doesn't even have to be exposed to the Internet globally.
[05:43.320 --> 05:45.660]  It doesn't have to have an static IP address.
[05:45.760 --> 05:51.560]  You can do a lot of gnat punching, because Onion addresses don't really need a public IP address.
[05:53.380 --> 05:58.380]  You can minimize the surface attack just by doing that and other stuff.
[05:59.020 --> 06:02.620]  You can do a stealth mode that I'm going to talk about a little bit.
[06:02.620 --> 06:17.180]  And you can, like, in a stealth mode, basically, even if you have the, even, like, somehow people find the address of the Onion address, they cannot, like, connect to it directly without the key, the actual key that they need.
[06:17.540 --> 06:23.040]  And you can use unique sockets to basically get rid of TCP in your setup.
[06:24.080 --> 06:26.120]  And they are censorship resistant.
[06:26.420 --> 06:28.480]  Nobody can censor an Onion address.
[06:28.480 --> 06:35.840]  And there is also, like, when you use Onion addresses, there is no DNS or BGP hijacking, poisoning bullshit.
[06:37.120 --> 06:38.820]  So here's the stealth mode.
[06:39.020 --> 06:46.360]  You basically need to add Tor rc file and add this option that it's Hidden Service Authorized Client.
[06:47.540 --> 06:58.980]  And in this mode, what happens is that each client that wants to connect to your Hidden Service or Onion Service has a unique Onion address with a unique key.
[06:59.520 --> 07:06.840]  So they should have, like, this, the first part is the Onion address, and the middle part is the unique key.
[07:07.260 --> 07:10.260]  And then the last part is the client.
[07:10.400 --> 07:14.280]  And you can see the user 1, 2, 3 have different Onion addresses and different keys.
[07:15.360 --> 07:25.760]  This helps because, you know, like, if you want to have a special infrastructure set up, which I'm going to talk about later a little bit.
[07:26.020 --> 07:29.120]  So what are the use cases of Onion addresses?
[07:30.060 --> 07:38.560]  What, like, is it, like, everybody thinks of Onion addresses just for, I don't know, like, a crazy website to deal drugs and whatever.
[07:39.220 --> 07:41.080]  But that's not the whole, the only thing.
[07:41.260 --> 07:46.920]  Because of all the good properties, health sector could, could take advantage of these things.
[07:47.700 --> 08:01.960]  The government services for, you know, like, a lot of the things that governments do, they don't necessarily need to collect all that information about people to, you know, like, we've heard about OPM hack and all of the different things.
[08:03.040 --> 08:08.920]  Tip lines, abuse complaints, whistleblowing platforms, you all know about SecureDrop and global leaks.
[08:09.500 --> 08:14.000]  There is a, there is a magazine that is only available over Onion.
[08:14.000 --> 08:15.300]  It's called Tourist.
[08:16.280 --> 08:16.680]  Yeah.
[08:16.980 --> 08:25.720]  And there are some person, like, some artists also dropped their whole album on, on Onion addresses.
[08:26.040 --> 08:31.180]  So if you wanted to download the album, you had to, like, go to the Onion address.
[08:31.540 --> 08:34.260]  You can secure your vulnerable infrastructure.
[08:34.280 --> 08:38.940]  You can take advantage of this in libraries, for, like, library catalogs and everything.
[08:39.240 --> 08:44.040]  This is, like, especially interesting for me because I work with Library Freedom Project.
[08:45.340 --> 08:50.540]  You can, Nathan of Guardian Project did a thing on Internet of Things, Home Assistant.
[08:51.200 --> 08:59.620]  Like, basically, if you are, if you are, if you want to run one of these things in your apartment, you, you don't need to expose the whole thing to the Internet.
[08:59.760 --> 09:05.160]  If you want to connect it from your mobile phone to that service, it doesn't have to be open to the Internet.
[09:05.380 --> 09:11.160]  You can just connect over Onion address and it's pretty, pretty much safer than Internet.
[09:12.940 --> 09:19.440]  So if, like, a lot of people, like, you know, have this question, like, what about Malish's exit nodes?
[09:19.540 --> 09:30.300]  What if, like, I don't know, some, some government agency or some bad actors are, you know, like, running a bunch of exit nodes and taking over all the running exit nodes?
[09:30.540 --> 09:35.980]  So basically, whenever you use Onion addresses, as David mentioned, you never use the exit nodes.
[09:36.020 --> 09:38.020]  You never exit the traffic.
[09:39.220 --> 09:41.420]  You never exit the Tor network.
[09:42.080 --> 09:46.020]  So the exit, none of the nodes actually know what's happening.
[09:46.220 --> 09:59.120]  There is, like, a Tor daemon on the server that, like, all the applications are connecting to that daemon server, that Tor daemon on the server over Unix socket.
[09:59.440 --> 10:13.680]  And there is a Tor daemon on the client side that all the, everything is, it is either going through Tor browser or if you're, you know, like, if you're doing a crazy creative setup, it's also using socket.
[10:14.060 --> 10:15.900]  So you're, like, only just Tor, Tor.
[10:17.060 --> 10:19.480]  You can use it for file sharing, right?
[10:19.580 --> 10:20.160]  Onion share.
[10:20.360 --> 10:27.120]  There is messaging applications like Ricochet that basically needs no server in middle.
[10:27.440 --> 10:33.820]  Like, there is no, there is, like, there's just, there are just two clients talking to each other and that's it.
[10:34.020 --> 10:34.980]  Like, there is nothing else.
[10:35.140 --> 10:38.420]  There, there is no need for OTR or anything because it's already encrypted.
[10:39.120 --> 10:54.220]  And the, you know, like, when two people are talking to each other, it's, it's fascinating because even if, like, the original developer of Ricochet, like, disappears tomorrow or I don't know if, like, he abandoned the project or whatever happens, you can still take advantage of it and it,
[10:54.220 --> 10:54.880]  it works forever.
[10:55.260 --> 11:02.800]  And the other thing is that, like, it, it basically eliminates the, the issue of metadata all in one.
[11:03.460 --> 11:04.600]  There is no username.
[11:04.740 --> 11:05.560]  There is no password.
[11:05.720 --> 11:06.960]  There is no metadata at all.
[11:07.100 --> 11:12.460]  Like, nobody, like, if somebody looks at your traffic, they can't even tell that you are chatting.
[11:12.680 --> 11:15.500]  Like, they can, they can, they can tell what you are exactly doing.
[11:16.440 --> 11:21.620]  You could run on cloud instances for, I don't know, like, a lot of different things.
[11:22.040 --> 11:30.200]  And you, I, I have a lot of repositories that are in my apartment and I only connect to them over Onion.
[11:30.740 --> 11:49.240]  And the interesting use case could be, like, all the mobile apps could, like, if you're an Android developer or iOS developer, you can basically put this service in if you want to, like, fetch config files or whatever, especially if you are in, uh, if your users are in censored areas.
[11:49.440 --> 11:54.020]  We will talk about that later because Facebook did something awesome, uh, with this regard.
[11:54.220 --> 12:00.000]  So I want to talk about, like, and a special use case that is actually, uh, this is based on true story.
[12:00.220 --> 12:02.000]  It's, it's already happening in the wild.
[12:02.200 --> 12:17.340]  So imagine that you are having, um, a web, you're running a website and that, that website, you're, like, doing things, uh, uh, correctly and, um, that HTTP, uh, that, that PHP website is, like, the app server is on a different VM.
[12:17.780 --> 12:26.220]  There is, uh, there is a, I don't know, like, Nginx reverse proxy on the web server that is serving, um, um, a static HTML.
[12:26.540 --> 12:35.040]  And you have a, you know, DB, uh, MySQL, like, like, imagine that this is the WordPress, uh, website with a bunch of vulnerable plugins and whatnot.
[12:35.380 --> 12:42.140]  And then, um, you have users, contributors to that website that need to basically connect to the app server.
[12:42.800 --> 12:55.180]  Now, if you, um, like, when you have this setup, even, like, even though it's, like, um, you know, distributed and, like, everything is compromised and moralized, and, uh, there is still the risk of exposure.
[12:55.360 --> 13:03.040]  There's the risk of exposure of your, uh, PHP, uh, server, application server, and there's the risk of exposure of your DB server.
[13:03.220 --> 13:12.560]  But if you do it over Onion, uh, what happens here is that only the user, like, each, each of these Onions are unique Onion addresses.
[13:12.940 --> 13:22.680]  So what happens here is that the database doesn't, none of these, not, not the database nor the application server have a public IP address.
[13:22.680 --> 13:28.220]  What happens is that they only talk to each other, the application server and DB over Onion.
[13:28.280 --> 13:43.000]  And especially if you do, uh, the stealth mode, as I explained, um, in previous slides, you, you need to have, like, a very unique, um, Onion address and the key to be able to connect to each other.
[13:43.100 --> 13:50.380]  So even if somebody finds the Onion address, uh, of your database, they are not going to be able to connect to it.
[13:50.880 --> 13:54.340]  Um, so it's gonna be, like, much, it, it makes it much, much harder.
[13:54.560 --> 14:03.300]  The other thing is that if you have multiple users, uh, multiple contributors, each contributor gets a unique, um, Onion address.
[14:03.500 --> 14:09.120]  So if, for example, one of them gets compromised for whatever reason, you don't need to change anything.
[14:09.380 --> 14:29.480]  You, all you have to do is to, like, basically, if I, um, go back to this thing, you just comment out, uh, that user, uh, uh, thing, uh, like, uh, that, that, that user, or, like, delete it from your Tor RC file, and they, that, basically, that Onion doesn't work anymore.
[14:29.560 --> 14:32.240]  And you, you leave the rest of the infrastructure in place.
[14:32.620 --> 14:34.120]  Nothing, um, compromises.
[14:34.700 --> 14:35.940]  Um, all right.
[14:37.920 --> 14:38.520]  All right.
[14:38.900 --> 14:39.180]  All right.
[14:39.180 --> 14:39.320]  Okay.
[14:39.640 --> 14:41.700]  So, uh, now it's gonna get extremely technical.
[14:42.020 --> 14:43.300]  So, uh, be careful.
[14:43.840 --> 14:44.280]  All right.
[14:44.540 --> 14:45.520]  Uh, Onion Services works.
[14:45.640 --> 14:50.220]  So we're gonna make, uh, an overview of how it in services, onion services, cheese, onion services works.
[14:51.000 --> 14:52.260]  Uh, the step one.
[14:52.480 --> 14:54.180]  So there's, there's multiple things here.
[14:54.360 --> 14:58.640]  Uh, in this slide, you'll see Alice, which is a client that will try to go to the service.
[14:59.060 --> 15:03.880]  And we have, in this case, uh, the big Tor network, which is a big cloud, uh, obviously.
[15:04.060 --> 15:06.020]  And then, uh, the introduction points.
[15:06.200 --> 15:08.560]  So this, this first thing is introduction points.
[15:08.780 --> 15:12.800]  The service will pick, at random, three introduction points.
[15:12.880 --> 15:14.680]  Introduction points are relays in the network.
[15:14.800 --> 15:16.300]  We have 7,000 of them in the network.
[15:16.300 --> 15:23.440]  So just pick three of And we'll create what we call a descriptor.
[15:23.540 --> 15:29.560]  So this descriptor is basically a text file that explains how to get to the service.
[15:30.060 --> 15:35.360]  Some fancy crypto and addresses of where to go and so on and so forth.
[15:35.660 --> 15:38.360]  The service will upload this descriptor to a directory.
[15:38.520 --> 15:40.380]  We call those HS directory.
[15:41.060 --> 15:42.260]  HS for it in service.
[15:42.460 --> 15:44.620]  Unfortunately, we cannot change that to onion service for now.
[15:44.620 --> 15:47.980]  So keep in mind, HS directory, it is an onion service directory.
[15:48.860 --> 15:53.720]  And then what's gonna happen is that Alice will fetch the descriptor from the directory.
[15:54.040 --> 15:59.220]  And with this information, with the descriptor, knows how to reach other service.
[15:59.520 --> 16:04.200]  At the same time, Alice will create a circuit to a rendezvous point.
[16:04.280 --> 16:05.660]  So the RP in this slide.
[16:06.560 --> 16:10.540]  This RP is, again, a random relay that Alice will pick.
[16:10.540 --> 16:15.960]  So what's going to happen is Alice will go to an introduction point.
[16:16.120 --> 16:19.500]  And Alice knows where it is because it's in the descriptor.
[16:20.080 --> 16:23.480]  And tells the service, please meet me at this rendezvous point.
[16:24.260 --> 16:26.680]  And then the service connects to the rendezvous point.
[16:28.260 --> 16:30.840]  And kills the circuit with the introduction point.
[16:31.340 --> 16:35.480]  And then we have a six ops circuit between Alice and the service.
[16:35.480 --> 16:39.880]  And it's very important because three ops one side, three ops on the other side.
[16:40.060 --> 16:41.380]  Well, we have anonymity both sides.
[16:43.400 --> 16:46.880]  So those are the basics of how our hidden services works.
[16:47.660 --> 16:53.560]  Please try to remember the introduction point here, rendezvous point in directory because we're gonna talk quite a bit about them.
[16:54.280 --> 16:55.060]  Directory here.
[16:55.540 --> 16:56.840]  So this is how...
[16:56.840 --> 16:59.780]  There's this problem here that I'll...
[16:59.780 --> 17:05.740]  Which directory Alice needs to connect to to get the descriptor since there's actually directory here, there's only one.
[17:05.880 --> 17:06.960]  But in reality, there are six.
[17:08.640 --> 17:12.020]  So the descriptor is uploaded to six different directories.
[17:12.480 --> 17:14.200]  In this case here, it's easy.
[17:14.860 --> 17:21.140]  Just create a hash, take the onion address, some time period, which is basically the time right now until UTC, blah, blah, blah.
[17:21.240 --> 17:21.960]  You can read the spec.
[17:22.160 --> 17:23.420]  And then the descriptive cookie.
[17:23.680 --> 17:24.540]  In this case, it's empty.
[17:24.700 --> 17:26.540]  So the descriptive cookie is used for authentication.
[17:26.680 --> 17:29.360]  So when you add a client, you have this extra key.
[17:29.360 --> 17:31.820]  Well, this is how this...
[17:31.820 --> 17:34.860]  With only this extra key, you know which is the descriptor ID.
[17:35.100 --> 17:35.980]  And then a replica.
[17:36.100 --> 17:37.500]  Replica is basically which H is there.
[17:38.180 --> 17:39.560]  And then you have a descriptor ID.
[17:39.680 --> 17:40.440]  So it's a long string.
[17:41.400 --> 17:46.920]  So this descriptor ID, when we base 64, 16 this one, and it gives us a bunch of numbers.
[17:47.660 --> 17:55.720]  And at that point, this is while the service and the client, remember, because this computation here, it is deterministic.
[17:56.400 --> 17:59.720]  So that means Alice and the service will compute the same thing.
[18:00.240 --> 18:04.580]  Now, with 3378, each relay network has a fingerprint.
[18:05.300 --> 18:10.760]  And then we're gonna upload this descriptor to the closest relays matching the fingerprint.
[18:10.940 --> 18:13.160]  In this case, 3378, 7B, and 7D.
[18:13.600 --> 18:15.460]  So we have pick our three relays in the network.
[18:15.680 --> 18:16.780]  You are in our HSDers.
[18:17.160 --> 18:19.920]  So this HSD gets a descriptor, stores it for 24 hours.
[18:20.060 --> 18:21.560]  Well, 18 to 24 hours, I'm telling you.
[18:22.500 --> 18:23.640]  So it looks like this.
[18:24.040 --> 18:24.720]  An hash ring.
[18:24.980 --> 18:28.820]  The descriptor ID starts, and then you upload to three Hs there.
[18:29.040 --> 18:30.480]  Replica 0, Replica 1.
[18:30.660 --> 18:33.800]  So we have symmetry in there, and we go over the network.
[18:34.300 --> 18:35.600]  We're spread out over the network.
[18:39.660 --> 18:41.980]  So now you know how it in service works.
[18:42.260 --> 18:43.480]  You know what the directory is.
[18:43.480 --> 18:53.500]  And all this, it's basically a design that was made in 2004, implemented, fixed over the years, but then cracks started to form.
[18:54.220 --> 19:01.940]  This is why we are going into this next generation in services that we will talk at length just after we're gonna talk about the cracks.
[19:02.980 --> 19:06.600]  So the first thing is that currently right now in...
[19:07.620 --> 19:08.420]  Oh, yeah.
[19:10.040 --> 19:15.300]  So in Tor, in the last two years, it was a huge effort to get rid of all the cryptography.
[19:15.440 --> 19:17.020]  Well, let's call it weak cryptography.
[19:18.000 --> 19:24.060]  And hidden services right now is the only remaining piece in Tor that uses RSC 124.
[19:24.500 --> 19:25.180]  Not SHA-1.
[19:25.260 --> 19:26.880]  SHA-1, there's other things, but RSC 124.
[19:27.180 --> 19:31.280]  So yeah, in this case, is this sync getting plausible with hidden services?
[19:31.400 --> 19:31.800]  We don't know.
[19:34.020 --> 19:35.180]  But it's a problem.
[19:35.180 --> 19:36.480]  Now, another thing.
[19:36.920 --> 19:38.700]  Directory gets the descriptor.
[19:38.780 --> 19:41.380]  Remember, the descriptor is a text file that informs you where to go.
[19:41.780 --> 19:44.900]  In the descriptor, you know, this is a snippet of a descriptor.
[19:45.040 --> 19:47.440]  You have this RSC public key, which we call the permanent key.
[19:47.720 --> 19:48.700]  Basically, your onion address.
[19:49.460 --> 19:58.740]  So it's very easy for any directory, any relay that has the HSR flag, gets descriptors, and it's in clear text, and then just compute the onion address.
[19:58.960 --> 20:00.760]  So what we call enumerating onion addresses.
[20:01.420 --> 20:08.740]  This attack has been going on, unfortunately, in the Tor network, and we are actively trying to detect that, actually, because it's a very harmful thing.
[20:09.000 --> 20:16.400]  Because people are just running relays, harvesting onion addresses, and not only that, but they're creating business model around that to crawl the dark web.
[20:16.700 --> 20:17.220]  Dark web.
[20:18.220 --> 20:19.800]  So it's really bad.
[20:20.120 --> 20:21.480]  And we know about that.
[20:21.700 --> 20:23.680]  There's literally hundreds of companies doing that.
[20:25.340 --> 20:33.260]  So this other thing, you can pull off a bunch of attacks, unfortunately, with being an HSDR, and also a guide.
[20:33.360 --> 20:34.340]  We're gonna talk about it at length.
[20:35.200 --> 20:37.180]  And what do we call the HSDR camping attack?
[20:37.440 --> 20:40.840]  So a relay can change its fingerprint very easily.
[20:41.460 --> 20:49.200]  And since this descriptor idea, and the computation, is deterministic, you know that in two years, where it's gonna be.
[20:49.380 --> 20:57.200]  Because the time period goes in, so you just compute this old hash, with the onion address, it's an invariant, this cryptor cookie, the replica, these old numbers that are.
[20:57.340 --> 20:59.020]  And the only thing that changes is time period.
[20:59.520 --> 21:03.600]  So this time period in two years, you just add two years, and you know exactly where it's gonna be.
[21:04.420 --> 21:06.980]  So relays to attack the network do that.
[21:07.080 --> 21:11.840]  They change their fingerprint to have this exact place where they need to be, like the HSDR 2 here.
[21:12.640 --> 21:14.400]  And then, they get the onion address.
[21:14.700 --> 21:17.500]  So let's say you wanna monitor WikiLeaks uploads.
[21:17.780 --> 21:30.600]  Well, you just take up WikiLeaks onion address, and you compute your fingerprint to be specifically the right one for the HSDR, and then you can just know who is, how many people are fetching WikiLeaks addresses.
[21:32.880 --> 21:36.240]  Here in the hash ring, basically, you camp, and you know where it is.
[21:37.680 --> 21:42.600]  So one of these attacks, I'm gonna go a bit faster, is the HSDR dynamization thing.
[21:42.880 --> 21:43.880]  It's a timing thing.
[21:44.100 --> 21:48.960]  So alien services have specific patterns of circuit creation.
[21:49.220 --> 21:53.240]  Remember, I'm gonna upload to directory, and then...
[21:53.240 --> 21:55.000]  Oh, in this case, it's client, sorry.
[21:55.100 --> 21:56.020]  The client is very specific.
[21:56.180 --> 21:56.860]  It's the same for it in service.
[21:57.780 --> 22:02.080]  I'm gonna fetch the descriptor from directory, open an RP circuit, connect the IP.
[22:02.600 --> 22:05.040]  So in this case, I put timings, if you can see.
[22:05.240 --> 22:06.620]  But the point is just to...
[22:07.320 --> 22:11.560]  If you're a malicious guard, and also a malicious HSDR, this is how the attacks goes in.
[22:11.760 --> 22:19.860]  You want to correlate who is getting which alien address on the directory, and as a guard, you know which client on which circuit is connecting...
[22:19.860 --> 22:21.140]  is getting this alien address.
[22:21.360 --> 22:22.520]  So use timings, here.
[22:23.880 --> 22:25.600]  First circuit, you get the directory.
[22:25.820 --> 22:27.100]  Two seconds later...
[22:27.100 --> 22:29.220]  One second later, you have...
[22:29.220 --> 22:29.900]  the circuit is killed.
[22:30.220 --> 22:31.000]  So it's very specific...
[22:31.000 --> 22:32.060]  distinct pattern here.
[22:32.740 --> 22:38.640]  What's gonna happen is that Alice creates an RP connection and an RP connection, and then at the same seconds.
[22:38.900 --> 22:39.820]  So noticeable again.
[22:40.580 --> 22:44.340]  And then the circuit is killed at the IP, wants to introduce herself, And then it goes to the RP.
[22:44.620 --> 22:48.060]  And once the RP is done, well, traffic goes through the circuit.
[22:48.780 --> 22:52.000]  So, you see this very, very distinct pattern.
[22:53.100 --> 22:58.220]  A, A, A, three different circuits, timings, and then, oh, you know which onion address is.
[22:58.300 --> 23:01.280]  In this case, it's a bit difficult to pull off because you have guard and directory.
[23:01.500 --> 23:04.300]  You need to be the malicious attacker that needs to control both.
[23:05.080 --> 23:08.260]  And remember, your guard also rotates every three months.
[23:08.260 --> 23:17.380]  And one of the reasons is we don't want your client or hidden service to rotate guards quickly so that the attacker can make you pick his guard.
[23:19.140 --> 23:21.540]  Now, this is a much more fun attack.
[23:22.400 --> 23:25.360]  Okay, so here is another interesting attack.
[23:26.420 --> 23:34.160]  Imagine that there is an attacker, that pumpkin thing on the top right, which wants to learn the guard node of an onion service.
[23:34.160 --> 23:38.420]  Guard node is the first hop of every circuit from an onion service.
[23:38.580 --> 23:43.020]  So, it's basically the only relay on the whole network that knows the IP address of the onion service.
[23:43.360 --> 23:47.100]  So, it's a significant relay for that onion service, basically.
[23:47.620 --> 23:53.420]  Now, imagine that the pumpkin has also set up a few middle relays around the network, malicious, bad relays.
[23:53.820 --> 23:56.480]  And here is the attack that it can pull off, basically.
[23:56.840 --> 24:00.820]  It knows the onion address of the onion service.
[24:00.820 --> 24:03.140]  So, for example, the Wikileaks onion service.
[24:03.500 --> 24:08.500]  And since it knows the address, it can pretend to be many, many clients.
[24:08.740 --> 24:13.960]  It can pretend to be 9,000 clients and try to establish 9,000 circuits to the onion service.
[24:16.460 --> 24:18.740]  And, well, let's move to the next slide, actually.
[24:18.900 --> 24:19.760]  It's more graphical.
[24:19.760 --> 24:27.340]  So, imagine that the pumpkin on the right asks the onion service on the left to establish 9,000 circuits.
[24:27.560 --> 24:30.680]  Because it pretends to be 9,000 individual clients.
[24:31.000 --> 24:36.680]  The onion service has to do this because it doesn't know that the attacker is actually one bad guy.
[24:36.960 --> 24:38.600]  So, it starts creating circuits.
[24:39.200 --> 24:44.000]  And every time it creates a circuit, it uses the same guard node, but it changes the middle node.
[24:44.080 --> 24:47.400]  The middle node is a different random relay every time.
[24:47.400 --> 24:59.980]  And since the attacker has middle nodes on the network, eventually, like, if it asks for enough circuits, eventually, the onion service will pick one of the attacker-controlled middle nodes.
[25:00.140 --> 25:07.660]  So, for example, the second circuit on that diagram has M2, which is red, and it's attacker-controlled.
[25:08.080 --> 25:21.460]  At that point, if the attacker can realize that, indeed, the attacker-controlled M2 is on the circuit, which is something that they can know because the attacker, for example, has a circuit to the hidden service and can send the signal.
[25:21.620 --> 25:24.860]  It can send, like, traffic, no traffic, traffic, no traffic.
[25:25.060 --> 25:29.600]  And this can be monitored by M2 and figure out that it's indeed in that position.
[25:30.200 --> 25:36.860]  Then M2 can just look on the previous hub and be like, ah, that's the guard of the onion service.
[25:36.860 --> 25:39.980]  And hence, it can discover the guard, basically.
[25:41.420 --> 25:48.040]  And since it knows the guard of the hidden service, it's useful knowledge, in general.
[25:48.200 --> 25:54.480]  You can then move to other attacks, since that node is the only node that knows the IP address of the onion service.
[25:56.880 --> 25:58.060]  So that's the attack.
[25:58.100 --> 25:59.960]  We're going to talk about defenses after.
[26:03.610 --> 26:11.970]  All right, so those attacks you saw with the HSDR harvesting onion addresses, this guard thing, are actually huge problems.
[26:12.490 --> 26:16.150]  So the next generation of onion services tries to address some of those.
[26:16.430 --> 26:19.050]  And let me tell you, it's not an easy thing.
[26:20.150 --> 26:22.310]  First of all, of course, yeah, better cryptography.
[26:22.490 --> 26:26.970]  You get a curve, everyone gets a curve, and we use SHA-3 also.
[26:27.190 --> 26:30.870]  So, yeah, great, amazing, better cryptography.
[26:30.870 --> 26:34.910]  Now, this is a problem.
[26:35.210 --> 26:40.690]  As I told you, business models are getting created on this and making money, blah, blah, blah.
[26:41.370 --> 26:45.750]  So we have this problem where time period is predictable and so on.
[26:45.830 --> 26:53.450]  We have the same descriptor ID equation there with a nice timeline showing you where different descriptor ID changes.
[26:54.050 --> 26:57.050]  At 11, it changes to a new one and so on and so forth, so you can predict it.
[26:57.590 --> 27:05.930]  So one of the solutions that happened at Tor is that we decided to create, to add a random value to this.
[27:06.150 --> 27:10.150]  But it's kind of difficult to add a random value that Alice doesn't know, only the service knows.
[27:10.310 --> 27:12.810]  So if only the service knows, well, Alice can't find it.
[27:13.790 --> 27:19.630]  So the shared randomness is basically you have there the eight directory authorities in the network.
[27:19.910 --> 27:27.050]  So a quick thing, if you don't know what directory authorities is, it's basically eight trusted machines around the world with trusted operators, we hope.
[27:28.110 --> 27:31.610]  And every relay uploads information to the directory authorities.
[27:31.710 --> 27:37.130]  The directory authorities gets this information, which is a server descriptor, again, a text file, and create a consensus.
[27:37.390 --> 27:42.130]  So they all vote, and they see the same thing, and they create a consensus.
[27:42.530 --> 27:46.810]  This consensus is a view of the network, all the relays, how to connect to them, and so on and so forth.
[27:47.030 --> 27:52.370]  But also, we added this thing where they're gonna, every 24 hour, they agree on a shared random value.
[27:52.370 --> 27:58.110]  So they all create commits, and then they're gonna reveal, so there's a commit and reveal phase, if you're familiar with this.
[27:58.350 --> 28:02.210]  And then they reveal, and then they mash up all the commits, and it creates a random value.
[28:02.530 --> 28:13.730]  And because of this consensus, okay, let's call it technology, happens, all directory authorities create the same consensus, thus the same random value, and then publishes it.
[28:13.910 --> 28:18.690]  So it's a bit like the NIST random beacon, I think, but in this case, it's trusted.
[28:22.110 --> 28:33.730]  So we add this random value, and then it's great, because now the descriptor ID changes every 24 hour, and thus the camping attack doesn't work, because it takes you five days to become an HSDR.
[28:33.970 --> 28:39.730]  So if it changes every 24 hour, and you rotate your key like a crazy, well, you can camp.
[28:40.090 --> 28:45.090]  Now the second thing, well, it's one of the main changes here.
[28:45.090 --> 29:03.090]  The other thing, I don't think we have a slide about it, but the descriptor ID, in the next generation in services, the onion addresses in the descriptor, we use this crazy trick key blinding thing, makes it that the hidden services cannot read the onion address.
[29:03.450 --> 29:09.810]  They cannot learn the onion address, but if they have the WikiLeaks onion address, they get the descriptor, they can hash it and get the descriptor ID.
[29:09.930 --> 29:13.270]  So they can know that this descriptor is WikiLeaks, but they cannot learn onion addresses.
[29:13.730 --> 29:15.690]  That's a new improvement also in the next generation.
[29:16.170 --> 29:20.790]  So this took us a long time to get work.
[29:21.530 --> 29:35.610]  Weirdly, engineering, it was very complicated, but now we have Moria 1, it's running it, and in the next version, 0.29, which is stable around October of Tor, all those directory trees should run it, and then Tor will create a shared random value every 24 hours,
[29:35.770 --> 29:39.090]  which is great, because then other applications can use it to other projects and so on and so forth.
[29:39.130 --> 29:40.710]  We believe it's fairly trusted.
[29:42.270 --> 29:44.530]  I'll go past this to George now.
[29:47.030 --> 29:58.770]  Okay, so currently, the Onion addresses, this thing on the top, the 16 characters, is basically 80 bits of a hash of the public key, base 32, or something.
[29:59.150 --> 30:11.630]  And this is basically 80 bits of security, which is not enough in this case, because someone can brute force these 80 bits and get an equivalent address, and then they can basically impersonate a hidden service.
[30:11.990 --> 30:15.850]  So moving to bigger addresses is something we definitely need to do.
[30:16.270 --> 30:34.470]  And because of the whole key blinding thing that David just described, where we basically defend against the attack, where the HSDR just sits on the hash ring and harvests Onion addresses, when we fix this attack, we basically had to move from the address being the hash of a public key,
[30:34.470 --> 30:39.690]  to the address being a public key itself, specifically an ED-25519 public key.
[30:40.090 --> 30:42.050]  And these things are not so small.
[30:42.170 --> 30:43.730]  They are actually quite big.
[30:43.770 --> 30:48.550]  And if you turn them into characters, you get to see 52 characters.
[30:48.550 --> 30:49.670]  It's the thing on the bottom.
[30:49.870 --> 30:50.710]  It's quite big.
[30:50.990 --> 30:52.830]  We're not even joking about this.
[30:58.330 --> 31:07.890]  I mean, the usability kind of breaks down, because it's not like you can memorize 16 characters, but 52 characters starts to become quite lengthy.
[31:08.330 --> 31:14.210]  And we will need to address this UX disaster in some way.
[31:15.970 --> 31:29.590]  potentially by building, like, some sort of pet name, address book system in TBB, or we have some ways where we can bring 52 characters down to, like, 48, 46.
[31:33.890 --> 31:41.830]  But, you know, there is no clear path how to bring it down to something human-readable, like 16 or something.
[31:41.830 --> 31:48.770]  We don't know, we, this is still one of the things we, we should, the, the, the UX things that we need to figure out for the next version.
[31:49.630 --> 31:53.150]  Um, okay, so this might have been interesting.
[31:53.970 --> 32:10.610]  Um, okay, so the attack I described before, where basically the attacker sets up middle, middle relays around the network, and then forces the onion service to create over 9,000 circuits, and it eventually hits the, the malicious middle nodes.
[32:10.610 --> 32:19.430]  Um, uh, so that, to, to, to get the guard of the hidden service, um, we have, we have, uh, a possible design to fix this.
[32:20.110 --> 32:26.090]  Um, it's this, it's, uh, also seems quite complicated, but it's actually not that complicated.
[32:26.330 --> 32:37.950]  But anyway, the, the idea here, the very rough idea, is that instead of, instead of, for every circuit, the hidden service picks a different middle node, um, we, we have guard sets.
[32:38.330 --> 32:46.330]  So basically, instead of only pinning down the first node, the guard node, we also kind of pin down the second node and the third node.
[32:46.610 --> 32:58.550]  So, um, so in this case, we keep the guard node, the first hop, for three months, The second layer guard node for a little bit less, like a few days, and the third layer guard node for a few hours.
[32:59.170 --> 33:11.050]  So if the attacker tries to do the same attack again, where it sets up middle relays on the network, the onion service will not, every time it makes a circuit, will not pick a new random relay.
[33:11.250 --> 33:14.870]  It will only rotate second layer guards every 11 days.
[33:14.870 --> 33:23.390]  So only every 11 days, the attacker has a chance to become the middle relay of the onion service, basically.
[33:23.630 --> 33:26.370]  So this slows down the attack quite a bit.
[33:26.690 --> 33:31.370]  And we're still tweaking the parameters and working on the proposal.
[33:31.670 --> 33:33.550]  It's called Proposal 247.
[33:33.550 --> 33:37.750]  You can Google it, and maybe you can find more information about it.
[33:39.530 --> 33:55.630]  Okay, on the happier side, another future improvement on hidden services is on scalability, because we have many people that want to run onion services in a more robust enterprise manner.
[33:55.950 --> 34:02.330]  And currently, this is not possible, because there is only one hidden service that accepts clients.
[34:02.670 --> 34:10.070]  And usually, in serious business environments, you have round robin and load balancing and all that shit.
[34:10.350 --> 34:19.990]  So we have this software called Onion Balance that we have not actually promoted at all for some reason, but you guys should know it.
[34:21.350 --> 34:40.210]  It's basically a way to set up multiple identical hidden services, say eight or something, and then you basically take all these hidden services, and you build a super descriptor that contains all that information, and you use that as your address.
[34:40.650 --> 34:51.630]  So clients, when they take that super descriptor and they connect to one intro point out of that descriptor, it can go to any of those eight individual onion services.
[34:51.790 --> 34:55.610]  So basically, you get load balancing on the introduction point layer.
[34:56.890 --> 34:59.150]  It's actually quite easy to use.
[34:59.750 --> 35:06.570]  You just have to set up N hidden services with the same web root or whatever, and then point Onion Balance to them.
[35:06.710 --> 35:08.430]  And then Onion Balance will do all the rest.
[35:08.970 --> 35:12.150]  You can get the GitHub link there and try it out, please.
[35:12.170 --> 35:15.470]  I think we will be quite interested in your experience.
[35:17.970 --> 35:18.450]  Okay.
[35:18.690 --> 35:28.370]  So this is another, this time, performance improvement, mainly designed for Onion services that are not meant to be anonymous.
[35:28.850 --> 35:30.970]  Yes, there are this kind of Onion services.
[35:31.410 --> 35:37.530]  For example, blockchain.info has an Onion service that is not anonymous and they don't care for it to be anonymous.
[35:37.830 --> 35:50.430]  But they still want an Onion service so that they get the protections of Tor and also that their Tor clients do not go over exit nodes and the exit nodes change Bitcoin addresses and all that shit.
[35:50.670 --> 35:55.810]  So basically, blockchain has an Onion service that they don't care to be anonymous.
[35:56.070 --> 36:01.510]  And for them, the Onion service, such an Onion service does not need to have a three hop circuit.
[36:01.690 --> 36:09.610]  It can just connect directly to the rendezvous point and get better performance because it doesn't do three hops.
[36:09.690 --> 36:10.850]  It just connects directly.
[36:10.850 --> 36:18.210]  So, single Onion services are these Onion services that are, that have better performance but they lose anonymity.
[36:18.350 --> 36:21.790]  It's for specific use cases like blockchain, Facebook, and all that stuff.
[36:22.250 --> 36:30.530]  And we find it quite interesting because it reduces load on the network and it still makes a client, the clients remain anonymous, of course.
[36:30.670 --> 36:32.850]  Nothing changes on the security of the clients.
[36:33.090 --> 36:36.790]  And the clients have a much better experience, let's say.
[36:39.790 --> 36:40.310]  Okay.
[36:40.310 --> 36:40.370]  Okay.
[36:40.730 --> 36:45.830]  So, these are some, some selections of the developments we're currently doing.
[36:46.030 --> 36:49.850]  Believe me, there are more things that are happening but they don't fit in this talk.
[36:50.590 --> 36:55.910]  And, and we just want to let you know that we're actively developing this stuff.
[36:56.130 --> 37:00.710]  We're a few developers that are, are working more or less on this thing.
[37:00.710 --> 37:07.210]  And, we always need help in, in analyzing the design, security analysis and all that stuff.
[37:07.710 --> 37:10.030]  You can check the Tor Dev mailing list.
[37:10.150 --> 37:12.370]  This is where we do our design work basically.
[37:12.650 --> 37:15.710]  If you, if you check the archives, you can see various proposals.
[37:15.710 --> 37:21.690]  All the things we described so far exist in, in, in like, proposals, tech proposals.
[37:22.410 --> 37:26.290]  Um, and also we have limited development firepower.
[37:26.470 --> 37:37.530]  So, if you're good at testing code, reviewing code, uh, or whatever, it's show up to our IRC channel and, uh, ask for, uh, ask for a task or something.
[37:37.530 --> 37:40.350]  We're usually friendly people, overloaded friendly people.
[37:40.590 --> 37:44.790]  So, we will try to, to direct you correctly.
[37:45.330 --> 37:51.630]  Um, and, uh, we're reaching the final stage of this talk with the takeaways.
[37:53.030 --> 37:53.250]  All right.
[37:55.810 --> 38:01.250]  So, here are some of the tips to keep your Onion addresses safe and secure.
[38:01.430 --> 38:05.190]  First of all, don't run relays, uh, if you're running an Onion address.
[38:05.190 --> 38:08.230]  If you're running a relay, it's basically reveals your Onion address.
[38:09.050 --> 38:15.030]  Um, use Unix sockets whenever you can to avoid, like, TCP connections altogether.
[38:15.490 --> 38:16.870]  It's amazing security.
[38:17.150 --> 38:18.650]  Keep your Tor up to date.
[38:18.870 --> 38:28.370]  Um, like, just don't run ancient Tor version and, you know, expect, excuse me, the least, um, like, you know, the recent security.
[38:28.590 --> 38:29.510]  Like, it's not gonna happen.
[38:30.190 --> 38:32.430]  Um, audit your config files.
[38:32.430 --> 38:36.350]  Like, um, a lot of people make a lot of mistakes in their web servers.
[38:36.490 --> 38:48.650]  For example, like, there is this thing in, um, in Apache, apparently, that, um, mod, um, status, or something like that, that basically leaks a lot of information about all the people who are connected to that web server.
[38:48.970 --> 39:00.830]  If you go to that, um, I know it's, it's a lengthy link down there, but, uh, if you search the Internet for, um, Rise Up, um, Onion Services Best Practices, you can find that link.
[39:01.310 --> 39:10.670]  Um, good people of Rise Up have put together, uh, best practices document on how to run Onion Services, um, with the most security.
[39:12.050 --> 39:25.750]  Um, use a stealth authentication whenever you can, because that way, even if you leak the, at your Onion address, um, they can't connect to it, because it's, you know, like, uh, they need the key.
[39:25.910 --> 39:28.810]  And also because you can recycle those things pretty quickly.
[39:29.310 --> 39:36.650]  All it takes is just basically, uh, commenting one line in your, um, Tor RC file and restarting your Tor client.
[39:36.950 --> 39:37.510]  That's it.
[39:37.870 --> 39:39.250]  And, um, OPSEC.
[39:39.250 --> 39:42.390]  Like, I mean, you can't, like, you know, I don't know.
[39:42.630 --> 39:45.690]  Um, you, you, you probably know, um, enough about this.
[39:45.810 --> 39:55.850]  Like, if you have bad OPSEC, you can't, like, if you, if you do everything else wrong, you can't, uh, put your life and, and activism on, um, on just the technology itself.
[39:56.350 --> 39:58.430]  Um, it's, I think it's very important.
[39:58.590 --> 40:04.150]  Like, if you're, like, especially for, for, um, activist use cases in crazy situations, especially in Middle East.
[40:04.650 --> 40:15.410]  Um, so here, um, like, we need a lot of, like, you know, sort of, uh, I, I think it, it's, it's one of the things that we need, uh, community to get more involved in this kind of things.
[40:15.630 --> 40:21.170]  We need more creative ideas and, um, experiments with, uh, with Onion Services.
[40:21.590 --> 40:28.170]  Um, all the, all the, um, interesting use cases actually came from the community, not the Tor project itself.
[40:28.770 --> 40:35.110]  Um, like, two good examples of that, um, is, um, Onion Share and Ricochet and Pond, actually, three.
[40:35.110 --> 40:39.990]  Um, I think Ricochet was, the, the idea was based on Pond.
[40:40.110 --> 40:40.570]  Uh, but yeah.
[40:41.290 --> 40:56.490]  We need more, uh, more people and, like, legitimate organizations to run Onion Services and not just for their, like, having websites is, is one thing and having, like, different, different services, running different services over Onion is also another thing.
[40:56.490 --> 41:04.670]  Like, um, I check my email over Onion because, you know, uh, I basically avoid man in the middle attacks altogether.
[41:05.070 --> 41:20.270]  I also, uh, have this, um, set up on my, like, personal mail server that, uh, because I use, um, hidden service authentication, only I can connect to that, um, main server over IMAP and, and nothing else, you know, can get in.
[41:20.790 --> 41:28.350]  Uh, so you can, like, we, we need more people to run Onion Services because, because that way we can, like, find the problems and everything.
[41:29.010 --> 41:40.950]  Um, many applications benefit from the, from the native Tor clients in their, um, native Tor clients in their, in their application and also, uh, native Onion addresses.
[41:41.570 --> 41:56.790]  Uh, Facebook did something, um, amazing on Facebook for Android that if you have, if you have Orbat installed and if you have Facebook for Android, it, um, there is an option that, um, it's, like, kind of, like, hidden option that appears that it basically sends all of your traffic over,
[41:56.790 --> 41:57.550]  over Onion.
[41:58.190 --> 42:08.630]  Um, GPG that, uh, just, um, started, you know, uh, supporting Tor, um, it's one of the options in the, in the recent, um, options Bitcoin uses, um, at Onion thing.
[42:10.430 --> 42:23.450]  And we also need more ways to quickly, uh, run this Onion Services, um, and, like, basically, if you need them, like, for, I don't know, like, ten minutes or ten hours and then, you know, that, that's it.
[42:23.650 --> 42:27.930]  You can, um, you, you need more ways to be able to, like, quickly deploy these things.
[42:28.030 --> 42:43.390]  I don't know if you're, uh, if you're Docker people, like, Docker Magic or whatever, um, tells, like, there is a Google Summer of Code, uh, project happening, uh, at Tor right now, that, um, one of the students is working on Tail Server, which has similar ideas,
[42:43.470 --> 42:50.270]  but, um, it's always better to have different approaches, uh, for different thread models and different, um, situations.
[42:51.550 --> 43:02.890]  And, uh, finally, we need, um, more ways, uh, to find useful and, um, you know, like, uh, relevant, um, Onion services or Onion sites.
[43:03.110 --> 43:08.090]  A lot of, um, like, there is, there is Amia that, uh, is the search engine.
[43:08.330 --> 43:24.950]  And there are, um, a bunch of tools, like, um, XMPP-client is a, is an XMPP client that has, uh, hard-coded the Jabber address of known, um, Jabber servers, like, um, like, Jabber.cc.de.
[43:24.950 --> 43:34.210]  Um, and we need, like, more things like that to happen, um, so we can, we can find these Onion addresses that are useful and we can use.
[43:34.710 --> 43:40.870]  Uh, RiseUp also has this, uh, page that basically every service that they run has an equivalent of Onion.
[43:40.870 --> 43:43.870]  So if you can, if you want to fetch your email over Onion address, you can.
[43:44.030 --> 43:48.590]  Or if you want to connect to RiseUp Jabber over Onion or use any other services.
[43:50.010 --> 43:50.670]  Thank you.
[43:57.980 --> 43:59.320]  Just a quick plea.
[43:59.320 --> 44:04.720]  Um, first of all, if you want to go to the, uh, we have time for questions now.
[44:05.160 --> 44:10.620]  Please use the microphone and please ask your question in the form of a question.
[44:16.880 --> 44:17.600]  Hey, guys.
[44:18.220 --> 44:18.960]  Um, hi.
[44:19.060 --> 44:19.640]  I'm Dan Lafar.
[44:19.760 --> 44:20.980]  I'm from George Mason University.
[44:21.480 --> 44:23.840]  Um, we work on cloud robotics a lot.
[44:24.620 --> 44:24.640]  Yes.
[44:24.640 --> 44:29.960]  You know, the bad actors are, are enemies, but our biggest enemy is latency.
[44:29.960 --> 44:34.720]  Uh, so I, I like this, but have you done any tests for latency?
[44:35.020 --> 44:36.040]  And what, what could I expect?
[44:36.400 --> 44:38.800]  Uh, any additional latency, basically.
[44:42.880 --> 44:51.300]  Um, yeah, I, I, I, I actually don't know exactly what kind of latency you expect and you, you would like to have.
[44:51.300 --> 44:57.100]  Um, I don't think you can treat the Tor as a real time system where the latency is well known and everything.
[44:57.940 --> 45:02.740]  Um, sometimes the latency is much better than you would expect from a thing that has six hops.
[45:03.240 --> 45:11.000]  But, uh, in general, and depending on the threat model of your, of your things, because, uh, maybe they don't need to be pure anonymous.
[45:11.020 --> 45:12.100]  They can have less hops.
[45:12.220 --> 45:12.540]  I don't know.
[45:12.620 --> 45:14.660]  They can be single onion services or something.
[45:14.980 --> 45:17.280]  Um, you can have improved performance.
[45:17.280 --> 45:24.780]  But, um, without knowing the exact specs of your, of your, of your thing, I cannot, uh, know if it's, uh, the right thing to do.
[45:24.900 --> 45:25.000]  Yeah.
[45:25.080 --> 45:30.180]  If latency is what you're fighting for, um, there needs to be more research.
[45:30.180 --> 45:31.020]  It's, uh...
[45:31.020 --> 45:32.820]  But you haven't done any tests on the latency.
[45:33.100 --> 45:33.440]  Okay.
[45:33.920 --> 45:34.220]  Oh.
[45:34.560 --> 45:35.120]  I see.
[45:35.560 --> 45:36.180]  Thank you.
[45:36.340 --> 45:37.140]  Well, uh, thank you.
[45:39.180 --> 45:47.140]  So you mentioned, um, uh, Vanguard, the, the Vanguard system for, um, uh, avoiding the, the, uh, attack on hidden services guard nodes.
[45:47.440 --> 45:54.820]  It seems to me the main reason you need that is that an attacker can cause the, uh, onion service to make new circuits.
[45:55.640 --> 45:58.760]  Wouldn't that apply to other Tor clients as well?
[45:58.760 --> 46:03.940]  Is it, um, or are you considering using the vanguards for other, other clients?
[46:04.980 --> 46:05.560]  Um, okay.
[46:05.800 --> 46:13.620]  So for normal clients, you usually cannot force a Tor client to create an arbitrary number of circuits, as you can do for hidden services.
[46:13.820 --> 46:14.000]  Well, sure.
[46:14.060 --> 46:22.100]  But consider like a, um, a webpage running JavaScript that has a, uh, um, a cross-origin anonymous, uh, script thing.
[46:22.540 --> 46:24.620]  Presumably that, that will go in a different Tor circuit, right?
[46:24.620 --> 46:37.720]  Um, I actually don't know how circuit isolation works in this case, but indeed you can think that over time that any client will eventually create enough number of circuits that you, it will, it, it will hit your middle node eventually.
[46:38.700 --> 46:51.580]  Um, actually when we designed the Vanguard proposal, we actually thought of applying this to clients so that it's, uh, symmetric, you know, so that it's, uh, all the, all the, all the entities use the same path construction basically.
[46:51.580 --> 46:56.100]  So if we did it for hidden services, we would most probably do it for clients as well.
[46:56.300 --> 46:56.560]  Okay.
[46:56.740 --> 46:56.800]  Cool.
[46:56.960 --> 46:57.180]  Thank you.
[46:57.600 --> 46:58.920]  Also, thank you for the great work.
[47:01.420 --> 47:01.900]  Hi.
[47:02.720 --> 47:08.540]  Um, just how decentralized is the directory system and how are the directory nodes chosen by the network?
[47:11.040 --> 47:15.480]  Um, so decentralized, uh, basically there are eight servers around the world.
[47:15.720 --> 47:20.980]  Uh, there's two in the U.S., two in Netherlands, two in Germany, one in Austria.
[47:20.980 --> 47:22.040]  Uh, something like that.
[47:22.640 --> 47:26.300]  Uh, uh, they are chosen very carefully.
[47:26.340 --> 47:27.640]  Let me say it to say that.
[47:27.980 --> 47:31.920]  So they're always, there's no organization running in a direct or directory.
[47:32.180 --> 47:40.160]  It's always a person, uh, that we trust that the community knows this person needs to come to dev meetings, uh, with that most people actually met in person.
[47:40.500 --> 47:42.380]  Uh, so that's for the operator part.
[47:42.480 --> 47:46.600]  And the network part, we try to use also trust in networks.
[47:46.600 --> 47:51.260]  Uh, for instance, run it as rise up, some into universities, uh, and so on and so forth.
[47:51.820 --> 47:57.460]  Uh, we wouldn't run the directory, uh, for instance, instead of Etsner or VH or stuff like that.
[47:57.540 --> 47:58.560]  Anyway, they don't want that there.
[47:58.900 --> 48:02.180]  So that's as much security we have for director attorneys.
[48:02.320 --> 48:04.940]  Have you thought about using like a distributed hash table kind of a thing?
[48:06.080 --> 48:13.920]  Uh, there have been multiple, uh, proposal about, uh, making it better, less centralized in some ways and so on and so forth.
[48:14.120 --> 48:19.200]  But, uh, this, this directory attorney system, this consensus and the votes are actually extremely complicated.
[48:19.420 --> 48:28.700]  Uh, and then so ripping it out and changing that by like a distributed system or hash tables or you don't need trust on like 5% of the nodes.
[48:28.840 --> 48:30.600]  It's actually a huge piece of work.
[48:30.760 --> 48:32.260]  So, yeah, it would be nice.
[48:32.560 --> 48:34.400]  Uh, we just need, you know, more resources, I guess.
[48:34.720 --> 48:35.300]  Thank you.
[48:36.240 --> 48:45.800]  There are some, on this topic, there are some researchers from EPFL that are designing some sort of decentralized authority system and they're in discussion with the Tor developers.
[48:46.640 --> 48:48.500]  But it's a, it's a really complicated thing.
[48:48.640 --> 48:52.980]  Like the bootstrapping of P2P systems in general is a pretty hard problem.
[48:53.160 --> 48:58.000]  And this super node thing is, uh, one of the de facto ways to, to, to get through it basically.
[48:58.760 --> 49:00.220]  Hey guys, thanks for all your work.
[49:00.280 --> 49:00.980]  Just a quick question.
[49:01.160 --> 49:04.980]  Do you guys have any kind of an estimate of when this stuff will land and be publicly available?
[49:05.240 --> 49:06.660]  Rough, specific, anything?
[49:08.660 --> 49:09.440]  Uh, okay.
[49:09.960 --> 49:10.360]  Estimate.
[49:10.360 --> 49:13.840]  Um, so we, we broke that, we broke this thing in five steps.
[49:14.160 --> 49:16.300]  Uh, one through three.
[49:16.420 --> 49:18.240]  We had three and a half right now.
[49:19.580 --> 49:25.100]  So, I would not expect this and maybe, maybe like, okay, let's be optimistic.
[49:25.100 --> 49:27.160]  Like in a year around that.
[49:27.460 --> 49:36.200]  It's, uh, it's, uh, if you remember the slide yesterday from the others, uh, the other, uh, um, um, talk, we had this, uh, construction of onions, which is nice, which is nice.
[49:36.320 --> 49:37.180]  And it's just a problem here, right?
[49:37.180 --> 49:43.980]  Uh, so one thing we didn't say is that this hidden service current, hidden service design right now will live in parallel with the new system.
[49:44.260 --> 49:50.200]  And just for those two to work together in terms of codes and C codes, uh, it's, uh, it's, it's a lot of work.
[49:50.280 --> 49:51.440]  So I'll say a year.
[49:51.600 --> 49:52.000]  Great.
[49:52.180 --> 49:52.420]  Thank you.
[49:52.420 --> 49:59.300]  So, uh, on this topic again, we are literally two, three developers with, uh, not even full time, some of us.
[49:59.560 --> 50:04.840]  So, more funding, more developers would really accelerate this, uh, this task basically.
[50:05.140 --> 50:07.560]  Also, if you are a C developer, join us.
[50:09.940 --> 50:11.360]  Yeah, C developer, please.
[50:13.340 --> 50:15.220]  Hey, thanks for all your work, guys.
[50:15.540 --> 50:24.100]  Um, my question was, when you had that diagram where you were running those compartmentalized app server, DB server, all that.
[50:24.500 --> 50:33.060]  Um, and when you use a Tor relay between them, is there any way to kind of address that might not have enough bandwidth for you exactly?
[50:34.420 --> 50:34.900]  Or...
[50:34.900 --> 50:36.900]  Um, a Tor relay?
[50:37.520 --> 50:46.760]  Uh, when you had the app server, and the DB server, and you, yeah, it's way back there.
[50:46.960 --> 50:47.080]  Yeah.
[50:49.960 --> 50:50.520]  Uh...
[50:52.640 --> 50:53.200]  Uh...
[50:53.200 --> 51:03.600]  So, the, the, the, the reason that I ask is because it's, it's not, it's not a good idea to run Tor, uh, relays on any of the, um, any of the...
[51:03.600 --> 51:04.520]  That one right there.
[51:05.000 --> 51:05.420]  Yeah.
[51:05.420 --> 51:20.120]  Um, yeah, I, I, I meant between, like, the web server, app server, DB, when you're running, like, a Tor connection between the, all these servers, is there any way to kind of address that it might be slow and sluggish because there's not really enough bandwidth if it's not on your own network?
[51:20.600 --> 51:23.260]  Uh, it's not usually, uh, an issue.
[51:23.440 --> 51:35.240]  I run one of these stacks, and, uh, basically what happens is that app server pushes, uh, it's, if you, um, look at this, uh, image, actually there's only one way from app server to, to the web server.
[51:35.500 --> 51:35.940]  Mm-hmm.
[51:35.940 --> 51:41.620]  And, um, app server basically pushes to the Nginx, uh, reverse proxy every, uh, I think, hour.
[51:42.120 --> 51:44.340]  So, latency is not really, um, a big thing.
[51:44.580 --> 51:45.020]  Okay.
[51:45.280 --> 51:45.500]  Uh, yeah.
[51:46.040 --> 51:53.360]  Like, in this, in this scenario, there is nothing, like, there is no, like, literally real-time changes that needs to be pushed.
[51:53.360 --> 52:00.560]  But, um, I don't, like, I wouldn't expect, like, more, maybe, like, five minutes max, you would have, like, with caching and everything.
[52:00.860 --> 52:01.020]  Okay.
[52:01.340 --> 52:01.480]  Yeah.
[52:01.980 --> 52:02.340]  Thank you.
[52:02.540 --> 52:02.760]  Sure.
[52:05.380 --> 52:05.820]  Hi.
[52:05.980 --> 52:06.760]  Thank you for the talk.
[52:07.020 --> 52:08.960]  I had one question about risk.
[52:09.240 --> 52:15.920]  The HSDRD, uh, de-anonymization attack, uh, you mentioned that you can collect information about Onion address access.
[52:16.140 --> 52:17.640]  What kind of information could leak?
[52:18.000 --> 52:18.740]  What's the risk?
[52:20.360 --> 52:23.100]  So, if you pull off the attack, you can de-anonymize the client, basically.
[52:23.100 --> 52:25.500]  So, you know which client goes to which Onion address.
[52:25.840 --> 52:27.920]  So, it's a de-anonymized attack on the client side.
[52:28.220 --> 52:34.460]  If you get the guard, the guard knows with, uh, as direct, uh, direct connections, clients' direct connection to a guard.
[52:34.600 --> 52:36.700]  So, if you get the guard, you can de-anonymize the client.
[52:37.100 --> 52:39.780]  So, in this case, just keep in mind, it's getting the guard is not enough.
[52:39.880 --> 52:45.380]  You have to actually take down the machine, go there, get the net flow of the ISP, and, and, and you know which one it is.
[52:45.920 --> 53:00.040]  Uh, so, this is one of the reasons why we have, uh, uh, rotation periods at the Vanguard, Is that we expect that in 5 to 11 days on the second set, well, the takedown takes longer than that in the political system.
[53:00.700 --> 53:03.620]  So it's a hack, but this is what we have.
[53:03.820 --> 53:04.220]  Thank you.
[53:05.800 --> 53:06.280]  Okay.
[53:07.020 --> 53:07.940]  So, thanks.
[53:08.140 --> 53:10.260]  First of all, let's give them a big hand.
[53:13.280 --> 53:14.280]  But don't move.
[53:16.140 --> 53:22.260]  So if you are here, if you want to go to Cory Doctorow's keynote, which is in Lamar, Lamar is full.
[53:23.340 --> 53:26.220]  You will not get in if you leave here to go see it.
[53:26.300 --> 53:28.540]  It will be simulcast in this room.
[53:28.980 --> 53:34.540]  So if you want to go to the keynote, stay put is basically the way you're going to get to see it.
[53:34.620 --> 53:41.840]  And you'll see it on the big screen with surround sound and vibrato seats and everything.
[53:41.840 --> 53:46.060]  It's going to be just like reality, but better.
[53:47.720 --> 53:52.780]  Oh, by the way, since we are on this slide, I want to add a note that, like, you can basically...
[53:52.780 --> 53:57.100]  The amazing thing about this thing is that you can basically run a revolution from your basement.
[53:57.380 --> 54:03.760]  It can be, like, these three VMs could be, like, three Raspberry Pis, and nobody knows the location of it.
[54:03.760 --> 54:12.100]  And if you are even, like, I don't know, crazy geek, like me, you can even have this git repository.
[54:12.740 --> 54:27.940]  You can have, like, a puppet server, a puppet master, and, like, even the puppet master is running on Onion, and you don't even have access to these things physically, so you can just, you know, push to git over onion, And Git would push to this Puppet Master over Onion,
[54:28.140 --> 54:32.040]  and the Puppet Master would just push to all the different servers.
[54:32.300 --> 54:33.020]  Anyways, thank you.