In depth Tor encryption design details

Question

I am currently struggling with understanding the details of a connection in Tor, mainly because I try to understand PCTCP. In this paper the authors claim that the changes are local to the onion router which is using PCTCP and that IPSec completely replaces TLS in the sense of the security goals integrity, confidentiality and authenticity.

Fine. I understood the basic onion routing principle, I understood Tor (I guess) and I understood the intention in PCTCP, but when replacing TLS with IPSec, imho the changes can not be local to the onion router using PCTCP unless I have a wrong understanding of the Tor security architecture.

Tor uses onion routing, meaning onion proxy (OP) has negotiated three symmetric keys (K1-3) with each of the onion routers (OR1-3) on the circuit with the Diffie-Hellman key exchange. These are the keys for the "onion skins" which are wrapped off the data flowing down the circuit by the onion proxies. (I see no possibility to introduce IPSec here)

But is this the only encryption in Tor, or are the connections between the onion routers encrypted too? (TLS, would be replaceable by IPSec) If so, why is this necessary?

Further PCTCP states that to avoid an adversary to count the connections IPSec will be introduced. But the thread model defined in Tor assumes that an adversary can run its own onion router, with which he could count the connection even with IPSec enabled.

It would be fine if somebody could explain Tor connection design as a whole, including all the places where security mechanisms are used. I guess the nice illustration cited in every second thread in the web is not all Tor is made of.

Answer 1

Tor's TCP Connections

The PCTCP paper is claiming that Tor uses a single TCP connection with multiplexed data from several users. The single output buffer then requires a scheduler to encrypt/decrypt each user's data, and ensure that all of the processing of each data stream is correct. This can lead to dropped data in a packet, which causes the re-transmission of that packet, and causes overall latency in TOR.

PCTCP is changing how the connections are performed. They're proposing that rather than multiplexing users together in a single TCP session, each user would get their own dedicated TCP connection between Onion Routers (ORs). Tor has its own protocol for establishing keys between ORs. This operation can still be performed as usual, but now with a dedicated TCP connection. The goal here is to attempt to reduce data corruption and the subsequent re-transmission of packets.

Tor Protocol Communications

Tor uses TLS between ORs to protect its Tor protocol communication. Once the messages are completed, and the keys have been established encrypted data passes through the multiplexed TCP connection.

PCTCP doesn't change how the keys are exchanged it just spawns a new TCP session for each new user. It could use TLS sessions for these TCP connections if they wanted. The flaw in their design is that an adversary can witness the number of TCP connections, and traffic analysis on a PCTCP node could be performed. To counter this PCTCP wraps all communication between ORs in an IPSec tunnel. Essentially moving the multiplexing of data at the Transport level to the IP level. Since IPSec is performed at the IP layer the source and destination don't care what the TCP data is. The packets will be decrypted/encrypted, and the individual TCP connections will be processed normally by the Tor daemon. The PCTCP paper states that this makes the use TLS between ORs redundant. Which it does. You would now be tunneling within a tunnel.

Keep in mind that this is only between the ORs. The data between the OP and the entry node will continue to use a TLS connection to secure its communications. You can still gain significant performance since most of the dropped data and re-transmissions are due to the inefficiency of the ORs.

---

This is how they can claim that changes only need to happen on the ORs. The OP uses its same communication method with the entry node. The ORs need to enable IPSec, and use PCTCP to establish dedicated TCP connections on a per user basis. IPSec is enabled by default in all Linux distributions now. As long as the OR is configured correctly this tunnel can be established.

They don't really state how they handle a connection if the IPSec tunnel is rejected. I'd guess that their PCTCP client would just default back to a TLS connection. They also elude to the fact that even a single node upgraded to PCTCP in a circuit will improve performance. But it seems to me that for IPSec to work you would need at least two adjacent ORs configured with PCTCP. In their experiments they always have at least two.

I think I addressed each of your questions.