Re: [tor-bugs] #7679 [Tor]: Test integration of Minion with Tor relays

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7679: Test integration of Minion with Tor relays
-----------------------+----------------------------------------------------
 Reporter:  arma       |          Owner:                  
     Type:  project    |         Status:  new             
 Priority:  normal     |      Milestone:  Tor: unspecified
Component:  Tor        |        Version:                  
 Keywords:  tor-relay  |         Parent:                  
   Points:             |   Actualpoints:                  
-----------------------+----------------------------------------------------

Comment(by slight):

 Hi all,

 My name is Fitz and I wrote the uTLS code in the past, and just recently
 updated it to TLSv1.2, following all the OpenSSL coding style and
 conventions for enabling uTLS.  We have a simple in-house testing program
 and testbed to verify that records are successfully decrypted out of order
 (using artificial loss to force drops).  My collaborators Jana and David
 are in charge of the uTCP kernel patch.  Together, we are now looking at
 using uTLS in the Tor source code.

 @nickm - Your exactly right. In going through the Tor code, I see that it
 does not rely on OpenSSL to preserve write boundaries. As I'm sure you
 know, it reads the data from SSL_read() into a buffer and then reads the
 first N bytes from it. Two things come to mind: 1) The TLS spec states
 that an implementation is free to combine records as it sees fit, and 2)
 The OpenSSL implementation does not combine records (i.e., it preserves
 record boundaries) as far as I can tell.

 Obviously, this is not a robust solution, but for the sake of argument, if
 Tor writes only on cell boundaries (i.e., one, two, three, etc. cells at a
 time), then the *current* SSL_read() with uTLS or regular TLS will produce
 those complete cells on their boundaries.  This would mean the Tor code
 could assume that the result of an SSL_read() holds complete cells, and
 they can be processed.

 As a note, uTLS "predicts" the sequence number of unordered records so
 that they can be successfully decrypted. Does Tor use additional
 encryption for the cells themselves? If so, then you are correct in saying
 you'd need to predict the sequence number (or know somehow exactly how
 many cells are in the unreceived "gap"). If not, however, uTLS will give
 you cleartext cells that can be used and processed right away.

 However, even if we kind of cheat and rely on OpenSSL to preserve write
 boundaries, this incurs a substantial rewrite of the Tor socket code.  In
 my opinion, I think the rewrite might be beneficial because it would allow
 the Tor code to act like each read produces a datagram. This makes for a
 cleaner, more abstract processing loop, at the cost of enforcing datagram
 boundaries somewhere below (if it's not done for you already).

 On the other hand, if you're using TCP, you expect to be able to do things
 as they are: in-order and shift the data down, so it's probably not
 attractive to have to rewrite all that code. (Of course, this IS uTCP not,
 TCP after all :) )  The alternative path is to take a look at the
 fetch_from_buf() function and see how we can force reads along cell
 boundaries. One way we've done this in the past for another framing
 mechanism (COBS encoding) is to interpose a data queue between the socket
 read and the processing code. Each read adds data to the queue, and
 whenever a complete record resides in the queue, it is processed. This
 encoding scheme was not encrypted, however, and it was easy to identify
 the record header (a single marker byte).  So, if each cell, including its
 header, is individually encrypted, then this is not really possible.

 Long story long, the uTLS patch (about 650 lines including comments) for
 OpenSSL is in a good state now, and I can share it with you guys, and the
 uTCP kernel patch is similarly in a good state, and we should be able to
 share that with you guys as well.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7679#comment:4>
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