Latest / CyberPodcast / Tor Performance vs Security: What Really Needs to Improve | Paper Breakdown #18 | CyberPodcast

Transcript

Tor Performance vs Security: What Really Needs to Improve | Paper Breakdown #18 | CyberPodcast · CyberPodcast

• 0:00
  Welcome to this technical explainer.
• 0:02
  Today we're doing something really exciting.
• 0:04
  We are literally popping the hood on the Tor network.
• 0:07
  We're going to look way past the standard high level summaries
• 0:10
  and conduct A rigorous under the hood examination of Tors
• 0:13
  architecture. We'll explore its specific
• 0:15
  security models, it's data flow mechanics, and most importantly,
• 0:18
  the actual physical performance bottlenecks that dictate how
• 0:21
  this anonymity network functions out in the real world.
• 0:24
  OK, let's dive right in. Here's our agenda for today.
• 0:27
  We'll start with the network architecture, then move to
• 0:30
  circuits and data flows, queuing and traffic management, the
• 0:33
  security model, performance impact, and finally, structural
• 0:36
  weaknesses and challenges. Section 1.
• 0:39
  Tor network architecture. The big picture.
• 0:42
  Before we get completely lost dissecting microscopic TCP
• 0:46
  streams, we really need a bird's eye view, right?
• 0:48
  When a client wants to connect to a destination server on the
• 0:51
  Internet anonymously, they don't just send data directly.
• 0:54
  No way. Instead, they connect through
• 0:56
  this huge decentralized web of volunteer operated notes.
• 1:00
  As you can see mapped out here, the path always enters through
• 1:03
  an entry guard, bounces through an intermediate onion router,
• 1:06
  and finally pops out through an exit router before hitting the
• 1:09
  actual destination. This structured web that is the
• 1:12
  absolute foundational backbone of tours anonymity.
• 1:16
  Now, just to keep our computer science terminology razor sharp
• 1:19
  for the rest of this explainer, let's rigorously define those
• 1:22
  core components you just saw. First, we have the OP or Onion
• 1:27
  proxy. This is just the client
• 1:29
  application running on your local machine.
• 1:31
  Like the Tor browser itself, its main job is fetching network
• 1:34
  info and constructing those pathways.
• 1:36
  On the flip side, we have the OR or Onion router.
• 1:40
  These are the actual volunteer relay nodes that physically pass
• 1:43
  your data along. So the entire network literally
• 1:46
  relies on this dynamic back and forth between O PS and O Rs,
• 1:50
  Section 2 circuits and data flows.
• 1:53
  A user's journey. All right, zooming in a bit to
• 1:56
  follow a user's data hop by hop. When your onion proxy builds a
• 2:01
  circuit, it does so in a strict 3 hop sequence.
• 2:04
  First up, it connects to the entry guard, second, it extends
• 2:07
  that connection to a middle router, and 3rd, it connects to
• 2:10
  the exit router. Now, what's absolutely vital
• 2:13
  here is the cryptography. The user's data is encrypted in
• 2:16
  layers, literally like an onion using Diffie Hellman handshakes.
• 2:20
  Each hop along the circuit only holds the cryptographic key to
• 2:23
  peel off a single layer of that encryption.
• 2:25
  So think about it. The entry guard knows your IP
• 2:27
  address, but has zero idea what you're accessing.
• 2:30
  The exit router knows exactly what you're accessing, but not
• 2:33
  who you are. And that middle router?
• 2:35
  It just separates the two. This step by step cryptographic
• 2:38
  stripping is exactly what mathematically separates your
• 2:40
  identity from your destination. But you know, advanced
• 2:44
  encryption alone isn't really enough if an attacker can just
• 2:47
  sit back and analyze the shape and size of the data being sent.
• 2:51
  And that brings us to a really crucial technical detail.
• 2:55
  All data in Tor is rigidly standardized into fixed sized
• 2:59
  cells of exactly 512 bytes. By forcing every bit of traffic
• 3:03
  into these uniform blocks, Tor completely prevents basic
• 3:06
  traffic analysis. If an attacker is watching the
• 3:09
  network, they just see this continuous monotonous stream of
• 3:12
  identical 512 byte pieces. They can't easily correlate,
• 3:16
  say, a large incoming file with a large outgoing file, simply
• 3:19
  because everything is chopped down to the exact same uniform
• 3:23
  size. Section 3.
• 3:25
  Queuing and traffic management. The micro level.
• 3:28
  OK, stepping away from the clean theory of cryptography, we have
• 3:31
  to confront the very messy reality of network congestion.
• 3:35
  Tor's tiered buffer architecture is actually a massive
• 3:38
  performance bottleneck. Here's how it works.
• 3:41
  When a 512 byte cell arrives, it drops right into the operating
• 3:44
  systems kernel TCP receive buffer.
• 3:47
  Tor then pulls it into a 32 KB input buffer.
• 3:50
  After the router does its thing decrypting or encrypting the
• 3:52
  cell, it drops it onto a specific circuit queue.
• 3:54
  A scheduler then pulls from these circuit queues, places the
• 3:57
  cells into a 32 byte output buffer, and finally pushes it
• 4:00
  back to the kernel TCP send buffer to transmit to the next
• 4:03
  node. Basically it's a wildly complex
• 4:06
  multi tiered queuing system managing thousands of cells all
• 4:09
  at exactly the same time. And man, all that complexity
• 4:13
  introduces a massive structural headache.
• 4:15
  Fundamentally, different types of application traffic are
• 4:17
  forced to share the exact same overarching TCP connections
• 4:20
  between onion routers. So you might have a circuit used
• 4:23
  for heavy continuous file sharing like BitTorrent
• 4:25
  multiplexed onto the exact same OR to OR TCP connection as a
• 4:29
  circuit that's just being used for simple lightweight web
• 4:31
  browsing. Tor uses a label switching
• 4:33
  design, which basically means multiple independent user
• 4:36
  circuits are all funneled through single shared TCP pipes.
• 4:39
  Researchers actually call this the cross circuit interference
• 4:42
  problem. To put that into perspective,
• 4:45
  imagine a highway. Your interactive traffic, like a
• 4:48
  quick Http://web request, is a fast sports car.
• 4:52
  Now imagine bulk traffic like a massive BitTorrent download as a
• 4:55
  slow moving heavy truck. Because they are sharing the
• 4:58
  exact same single lane TCP highway between routers, the
• 5:02
  fast interactive traffic inevitably gets stuck behind a
• 5:05
  giant backlog of bulk data packets just sitting in the
• 5:08
  kernel's TCP buffers. Even if Tor's application layer
• 5:11
  desperately tries to prioritize your web browsing, once the data
• 5:14
  hits the colonel's TCP buffer, that sports car is trapped
• 5:17
  behind the truck. No way around it.
• 5:20
  Section 4, the security model protection and limits.
• 5:23
  So what does this all mean for your actual safety?
• 5:27
  Well, the absolutely crucial point here is that Tor is
• 5:29
  designed purely to protect against what's called a local
• 5:32
  active adversary. This means it defends against an
• 5:35
  attacker who can only watch or control a small fraction of the
• 5:38
  network, say your local Wi-Fi provider or maybe a handful of
• 5:41
  compromised routers. It is strictly not designed to
• 5:44
  defend against a global adversary who can monitor all
• 5:47
  traffic entering and exiting the network simultaneously.
• 5:50
  If a global attacker can watch both the entry and the exit of
• 5:53
  your circuit, they can simply use timing correlation to match
• 5:55
  up the traffic patterns and completely shatter your
• 5:58
  anonymity. Because Tor assumes this local
• 6:01
  adversary model, the main advanced threats we look at
• 6:03
  includes selective denial of service attacks, where malicious
• 6:06
  routers intentionally drop legitimate traffic just to force
• 6:10
  you on to compromise search X. Then there's side channel
• 6:12
  analysis, which looks at the timing or queue data we were
• 6:15
  just discussing. And finally, a ton of the
• 6:17
  system. Or AS level attacks, where
• 6:19
  massive global telecom providers might monitor both ends of a
• 6:22
  circuit as your traffic naturally routes across
• 6:24
  different Internet backbones. Section 5.
• 6:27
  Performance impact? The real data.
• 6:31
  So what does all this micro level architecture actually mean
• 6:35
  when you sit down and try to download a file?
• 6:38
  Looking at this cumulative distribution function for
• 6:40
  download times, we see a dramatic drop.
• 6:43
  The median download time for a standard 5 megabyte file
• 6:47
  plummeted from an excruciating 144 seconds back in 2009 down to
• 6:51
  just 14 seconds in 2015. That is a massive, highly
• 6:56
  tangible improvement. But take a look at the long tail
• 6:59
  on that 2015 curve. At the 75th percentile and
• 7:02
  above, download times still jump to over 25 seconds.
• 7:06
  The variance is huge, which means your actual day-to-day
• 7:09
  user experience remains highly unpredictable.
• 7:12
  So why the massive variance? Honestly, it boils down to
• 7:15
  volunteer hardware heterogeneity.
• 7:18
  If we look at the observed bandwidth distribution across
• 7:20
  all Tor routers, it reveals an incredibly steep curve.
• 7:24
  Get this over 60% of the routers in the network offer less than
• 7:27
  one MB per second of capacity. Only about 10% offer more than
• 7:31
  20 megabytes per second. And because a single Tor circuit
• 7:34
  requires 3 routers to function, your speed is fundamentally
• 7:37
  constrained by the slowest link in your specific chain.
• 7:40
  If your circuit randomly selects even one of these low bandwidth
• 7:43
  nodes, your performance is going to drop off a Cliff.
• 7:46
  Section 6 Structural Weaknesses and challenges the future.
• 7:51
  Zooming all the way back out to the macro level, the biggest
• 7:54
  overarching systemic issue threatening the network is just
• 7:58
  a stark numbers game. We have millions of daily users
• 8:01
  routing their Internet traffic over roughly 6000 volunteer
• 8:05
  onion routers. This incredibly unbalanced
• 8:08
  client to router ratio puts an enormous, relentless stress on
• 8:12
  the network's queuing capacity we talked about earlier.
• 8:14
  Tor is an absolutely essential tool, but its underlying
• 8:17
  infrastructure simply hasn't scaled at the same mathematical
• 8:20
  rate as its massive user base. To sum it all up, Tor absolutely
• 8:25
  must solve these core structural weaknesses to remain viable long
• 8:29
  term. First, the overhead of its
• 8:31
  centralized design where every single client has to constantly
• 8:34
  download an updated network consensus consumes massive
• 8:37
  amounts of bandwidth. 2nd, that wildly unbalanced client to
• 8:41
  router ratio we just looked at. And 3rd, the extreme resource
• 8:45
  heterogeneity of volunteer hardware, which directly causes
• 8:48
  that unpredictable latency. And remember, performance isn't
• 8:51
  just about user convenience here.
• 8:53
  In anonymity networks, performance issues directly
• 8:55
  impact security. If Tor is too slow, users leave.
• 8:59
  If users leave, the overall anonymity set shrinks, meaning
• 9:02
  the users who do remain have far less mathematical cover to
• 9:05
  actually hide within. Which really brings us to the
• 9:08
  ultimate technical paradox of low latency anonymous
• 9:12
  communication. Cantor mathematically and
• 9:15
  physically scale to accommodate millions of new users without
• 9:19
  completely redesigning the underlying TCP transport
• 9:22
  protocols that currently keep it anonymous.
• 9:24
  It is a deeply complex, fascinating balance between
• 9:27
  scale, speed, and absolute privacy, and it's a structural
• 9:32
  challenge that the brightest minds and network engineering
• 9:34
  are literally still trying to solve today.
• 9:37
  Thanks for joining me on this explainer.
• 9:39
  I hope you found it as interesting as I did.