[tor-bugs] #4680 [Pluggable transport]: Design, build, and document Morpher as a pluggable transport

[Tor Bug Tracker & Wiki]

#4680: Design, build, and document Morpher as a pluggable transport
---------------------------------+------------------------------------------
 Reporter:  karsten              |          Owner:  asn                      
     Type:  project              |         Status:  new                      
 Priority:  normal               |      Milestone:  Sponsor F: March 15, 2012
Component:  Pluggable transport  |        Version:                           
 Keywords:                       |         Parent:                           
   Points:                       |   Actualpoints:                           
---------------------------------+------------------------------------------

Comment(by asn):

 I'll write down some things I've been thinking lately, because me thinking
 on my own is not the most effective way of doing things.

 a) We should evaluate whether the final morpher transport should use
 'random sampling', or 'morphing matrices' to select a packet's final
 packet size.

 In 'random sampling', you have a packet size probability distribution of a
 target protocol, and you pick a random variable, and then you shape your
 packet to be of that size.
 By 'morphing matrices', I mean the technique described in the paper
 ''Traffic Morphing: An efficient defense against statistical traffic
 analysis'' which attempts to minimize the padding overhead imposed by
 packet size shaping.

 Since our morpher transport will try to turn Tor traffic into HTTPS
 traffic, as far as packet sizes are concerned, we should evaluate whether
 the 'morphing matrices' method is worth it. We can build a tool that uses
 both methods on a couple thousand packets, and see which method is more
 effective. If 'morphing matrices' is indeed more effective, we should see
 whether it's effective enough to justify its troublesome implementation.

 b) Since we want to look like HTTPS traffic, the outer layer of our
 traffic must be SSL.

 Unfortunately, it seems that our transport will have to build a second SSL
 layer on top of Tor's. If we didn't do that, and we let our transport
 morph the packet sizes of the original SSL layer of tor, that layer would
 look "morphed"; some packets would be splitted and others would be padded.
 In other words, it wouldn't look like normal SSL.

 The problem with a second SSL layer is not only the network overhead, but
 the fact that we will have to camouflage it, like we camouflaged Tor's SSL
 layer: very painfully. We will have to camouflage the certificates, and
 the SSL properties, and the SSL crypto values (DH modulus etc.).

 Maybe with some crazy hacking skills, we can expose some of Tor's
 camouflage into a file, that both Tor and morpher can use, similar to how
 ciphers.inc is independent from tor's code atm.
 Maybe with #4550, Tor's certificates will be exported to files, and
 morpher can use them too.

 But in any case, this will be messy and I can't find a good way to make it
 better.

 (A positive thing, which I'm not sure if it's possible (without
 refactoring obfsproxy too much), is that we might be able to use libnss as
 the client-side SSL library.)

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