[tor-bugs] #5280 [Obfsproxy]: obfsproxy transport functions do not understand TCP

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#5280: obfsproxy transport functions do not understand TCP
-----------------------+----------------------------------------------------
 Reporter:  asn        |          Owner:  asn
     Type:  defect     |         Status:  new
 Priority:  normal     |      Milestone:     
Component:  Obfsproxy  |        Version:     
 Keywords:             |         Parent:     
   Points:             |   Actualpoints:     
-----------------------+----------------------------------------------------
 Imagine you are trying to pass a large amount of data (more than 4096
 bytes) over the client-side of a transport. In this case, libevent
 calls downstream_read_cb() every 4096 bytes of data (is it
 EVBUFFER_MAX_READ?), which in turn calls proto_send(). This means that
 if a transport has headers, they are appended every 4096 bytes. Then,
 during proto_send(), the obfuscated data are appended to the 'dest'
 evbuffer.

 If the file was bigger than 4096 bytes, proto_send() will be called
 again (for the rest of the data), and a header will be added
 again. Then the new 4096 bytes of obfuscated data will also be added
 to the 'dest' evbuffer. Then on the next libevent loop, libevent will
 send all the buffered data to the wire. This means, that on the wire
 we will see a big fragmented TCP packet with multiple transport
 headers on it.

 How can we guarantee to our transports that their headers will be
 appended only to new TCP packets? A fragmented TCP packet with two
 bunches of HTTP headers in it doesn't happen in real life.

 Should we somehow implement the "Don't add stuff to 'dest', if 'dest'
 already has stuff in it."? Should we add it as the default behavior of
 proto_send? How much will it cripple performance? Does this make
 sense?

 As a secondary question, does EVBUFFER_MAX_READ add fingerprints in
 our traffic, when we send large amounts of data?

 (Arturo encountered this issue when implementing his HTTP transport,
 so I'm CCing him.)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5280>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs