2

I'm a mathematics student trying to understand Tor. I have little knowledge of networks and how exactly they function.

Up to now I (think I) understand the basic functionality of Tor. A route is generated first from the consensus list, and the packet (the message) is sent through that route. The packet is encrypted multiple times using the public keys obtained from the consensus list, and each relay strips away a layer of encryption before sending it on to the next relay (side question: how does this work with bridge relays? Is the message sent to a bridge relay first and then into the public Tor network, or does it move exclusively through bridge relays?). This means that the destination IP and IP of the sender are never in the same header of the packet and this is what gives Tor its relative anonymity.

Very often however I notice that SSL is brought up when discussions regarding Tor are made. I understand that SSL encrypts the data sent between the client and the server. But if this is the case I don't see how SSL is related to Tor, since they seemingly function on a different layer.

Edit: More specifically, I'm reading about how Iranian and Chinese authorities did "Deep Package Inspection" (i'm assuming this means that they looked at the contents of each packet) to look for SSL. Is this because SSL is used by default with encrypting the different layers in an onioned packet? If so, is there a reason that looking for SSL was enough to indentify a Tor connection?

1

The SSL and Tor are not parts of one problem. But the reason of meeting them together very ofthen lays within the network security area itself. Let me explain it - maybe abit over-deep-digging, but there's no too long proves ;) So :

  1. SSL = "Secure Socket Layer". It's a tool(kit), in another words, and in simplified ones, it cares about all the questions "how to add security/verification/authentication to the connecion, that is already made by network stack". It does not care AT ALL how the network stack works.
  2. Tor = "The Onion Router". It's a part of network stack, in another words, and in simplified ones, it cares about all the questions "how to connect from point A to point B". And that's it! It does not care about what point A will do with point B, even if there won't be a single communication at all.

So far, so good, then let me sort a different types of materials, when you can see theese two things(Tor and SSL) discussed together :

  • As a toolkit SSL is used in programmatical/software implementation of Tor. It's "an internals case". SSL is used to secure communications between Tor nodes and other members of Tor network as a part of Tor networking protocol. You can see attack vectors' discussions, Tor security and speed discussions in this kind of materials.
  • For an end-user, Tor is just a "secure kind of network jack", and there's a bunch of problems related to MitM-attacks, weak ciphers in SSL stack, problems related to sending plaintext/unencrypted data e.t.c. Theese problems have common criteria of occuring during network interoperation, and Tor network is just another kind of netwok(as a transport layer) where it does occurs. Here you can read something about "always using HTTPS", Perspectives Project and so forth. This kind of problems is not related to Tor directly, because they're happening all the time even during a regular network experience, for example a websurfing. But due to a big interest to de-anonymisation of darknets' users, there are slightly bigger risks of being attacked.
  • SSL speed applied to Tor network speed. As fot VPN's, so for Tor, there's a bottleneck. The network stack components based on encryption have a common speed problem, related to the encipherment-deciphering speeds. And - for example - if you're using Intel's AES instructions to speed-up AES(Rinjdael, actualy), you will see the speed boost of your network access through such a network stack component, including Tor.
  • Law/Regulations conformity. You know, that ciphers and their usage are regulated over the world, in every country you have a different law codex. And - "how to use cipher X or Tor itself to not to brak law" is a common question related to that matter

That's it! Feel free to ask if you have questions - I'll be glad to help!

1

But if this is the case I don't see how SSL is related to Tor, since they seemingly function on a different layer.

If you're doing some preliminary reading about networking, you're presumably looking at either the OSI Model or the Internet Protocol Suite. They're different ways of representing the network stack, and differ in the number of layers they split things into.

  • SSL (now called TLS) and HTTPS are Application layer protocols (OSI layer 7).
  • Tor is a SOCKS proxy, so sits below on the Session layer (OSI layer 5).

Therefore, your outgoing traffic is first bundled up with HTTPS/TLS, then passed to the lower layers, where it's bundled up by Tor, then TCP (layer 4) and IP (layer 3) respectively.

So yes, different layers. So why do we need HTTPS/TLS? Once your traffic leaves the Tor network at the exit node, all the Tor-related encryption has been stripped off. We need some other form of encryption to provide security until we reach our final destination, mainly to prevent things like Man-in-the-Middle attacks.

There's a nice interactive infographic on the EFF site showing what security both Tor and HTTPS (TLS) provides, and at which point on your traffic's travels.

side question: how does this work with bridge relays? Is the message sent to a bridge relay first and then into the public Tor network, or does it move exclusively through bridge relays?

Only the first, entry node is the bridge. The rest of the circuit is as normal.

1

Tor uses SSL to secure point-to-point connections between peers. The multi-hop onion routing protocol (with its separate layered encryption) is implemented over these individual links. Thus it was possible for Iran to block Tor connections simply by identifying the beginning of the SSL handshakes from a client to its guard nodes, and interrupting them. It was a heavy-handed approach as it also impacts regular SSL connections to e.g. websites (although other selectors could be used to ignore handshakes to known or allowed webserver).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.