[tor-bugs] #9022 [Pluggable transport]: Create an XMPP pluggable transport

[Tor Bug Tracker & Wiki]

#9022: Create an XMPP pluggable transport
---------------------------------+------------------------------------------
 Reporter:  asn                  |          Owner:  feynman 
     Type:  task                 |         Status:  accepted
 Priority:  normal               |      Milestone:          
Component:  Pluggable transport  |        Version:          
 Keywords:                       |         Parent:          
   Points:                       |   Actualpoints:          
---------------------------------+------------------------------------------

Comment(by feynman):

 Replying to [comment:42 rransom]:
 > Replying to [comment:41 feynman]:
 > > Replying to [comment:38 asn]:
 > > > Hey feynman,
 > > >
 > > > thanks for all the new features, and sorry for being less active on
 this lately.
 > > >
 > > > BTW, due to the encryption of TLS, I'm not sure how helpful the
 caching is, since all TLS records should look unique on the wire. For the
 same reason, zlib might not find much stuff to compress in your TLS
 traffic.
 >
 > > TLS encryption should be completely independent of caching. It is not
 caching the TLS packet, but the data it sends *before* it gets encrypted
 with TLS. The same goes for the zlib compression stuff.
 >
 > Tor connections are encrypted (and authenticated) using TLS before they
 reach your XMPP transport.

 That would imply the zlib compression would be quite useless when relaying
 Tor traffic, but the caching scheme should work all the same. The whole
 XMPP transport does no analysis on what it is reading. It simply passes on
 the data byte for byte. The caching scheme combined with id numbers for
 packets should help ensure chunks of data get to the proper destination
 consistently and in the right order.

 Whatever Tor does when it reads and writes to a TCP socket should work
 independently from the mechanism that actually delivers the data to its
 destination. My understanding is that the packet would ordinarily be
 encoded with an IP header and sent directly through a gateway to the
 internet.

 When using hexchat, the data is sent to a local TCP socket running hexchat
 (call it hexchat1). Hexchat1 then reads the data (thereby stripping it of
 its TCP header) and passes it over a chat server to another hexchat
 program (call it hexchat2) that sends the data to the appropriate ip:port
 (giving it a new TCP header in the process).

 The client thinks it is sending the data to hexchat1, and the server
 thinks it is receiving data from hexchat2, but the data itself is never
 changed. It might be broken into smaller chunks or combined into bigger
 chunks, and it might be delivered at unpredictable rates, but it is never
 altered.

 That at least is how this should work in principle.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9022#comment:43>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online