Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4680 closed project (implemented)

Design, build, and document Morpher as a pluggable transport

Reported by: karsten Owned by: asn
Priority: Medium Milestone:
Component: Obfuscation/Pluggable transport Version:
Severity: Keywords: SponsorF20120315
Cc: sjmurdoch Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

For sponsor F deliverable 8 we promised to work on a pluggable transport based on traffic morphing as described in this UNC paper. The name of this pluggable transport will be Morpher.

We promised to do the following things:

  • Implement an initial prototype of the traffic morphing code.
  • Integrate the prototype with obfsproxy.
  • Write a spec for the Morpher code (so everybody can know what exactly it does).
  • Write a spec for a protocol that Morpher uses.
  • Make contact with the "traffic morphing" research group at UNC, try to get them to review Morpher, try to get them thinking about next steps, and learn what else they're up to.

I'm optimistically assigning this ticket to asn even though he didn't explicitly say that he's going to lead this deliverable.

We should probably create child tickets for the substeps listed above that aren't completed yet.

Child Tickets

Attachments (12)

tor_cs.png (21.1 KB) - added by asn 7 years ago.
Tor Client->Server packet size prob. distr.
tor_sc.png (27.4 KB) - added by asn 7 years ago.
Tor Server->Client packet size prob. distr.
https_cs.png (45.6 KB) - added by asn 7 years ago.
HTTPS Client->Server packet size prob. distr.
https_sc.png (36.6 KB) - added by asn 7 years ago.
Tor Server->Client packet size prob. distr.
sc_log.txt (8.7 KB) - added by asn 7 years ago.
Snippet of the S->C morphing log
cs_log.txt (14.4 KB) - added by asn 7 years ago.
Snippet of the C->S morphing log
500_cs.png (49.7 KB) - added by asn 7 years ago.
Client->Server 500 packets overhead
500_sc.png (54.0 KB) - added by asn 7 years ago.
Server->Client 500 packets overhead
500000_cs.png (43.4 KB) - added by asn 7 years ago.
Client->Server 0.5m packets overhead
500000_sc.png (46.4 KB) - added by asn 7 years ago.
Server->Client 0.5m packets overhead
cs_overhead.tar.gz (292.6 KB) - added by asn 7 years ago.
tarball of many Client->Server overhead plots
sc_overhead.tar.gz (318.1 KB) - added by asn 7 years ago.
tarball of many Server->Client overhead plots

Download all attachments as: .zip

Change History (16)

comment:1 Changed 7 years ago 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.)

comment:2 Changed 7 years ago by asn

OK, wrt a), I made a small utility (analysis/gain.py in the morpher repository) which tries morphs thousands of packets using both traffic morphing _and_ direct sampling, calculates the total overhead, and plots the result. This should help us decide if traffic morphing is worth it.

I'm baking the plots right now, give me some minutes.

Changed 7 years ago by asn

Attachment: tor_cs.png added

Tor Client->Server packet size prob. distr.

Changed 7 years ago by asn

Attachment: tor_sc.png added

Tor Server->Client packet size prob. distr.

Changed 7 years ago by asn

Attachment: https_cs.png added

HTTPS Client->Server packet size prob. distr.

Changed 7 years ago by asn

Attachment: https_sc.png added

Tor Server->Client packet size prob. distr.

Changed 7 years ago by asn

Attachment: sc_log.txt added

Snippet of the S->C morphing log

Changed 7 years ago by asn

Attachment: cs_log.txt added

Snippet of the C->S morphing log

Changed 7 years ago by asn

Attachment: 500_cs.png added

Client->Server 500 packets overhead

Changed 7 years ago by asn

Attachment: 500_sc.png added

Server->Client 500 packets overhead

Changed 7 years ago by asn

Attachment: 500000_cs.png added

Client->Server 0.5m packets overhead

Changed 7 years ago by asn

Attachment: 500000_sc.png added

Server->Client 0.5m packets overhead

Changed 7 years ago by asn

Attachment: cs_overhead.tar.gz added

tarball of many Client->Server overhead plots

Changed 7 years ago by asn

Attachment: sc_overhead.tar.gz added

tarball of many Server->Client overhead plots

comment:3 Changed 7 years ago by karsten

Resolution: implemented
Status: newclosed

asn said today:

08:46:05 < asn> #4680 is finished.
08:46:09 < asn> the report is the product.
08:46:36 < asn> we kinda decided that traffic morphing, in its current technology 
                state, is not the definite way to go.
08:46:41 < asn> and the report explains why.

Closing.

comment:4 Changed 7 years ago by karsten

Keywords: SponsorF20120315 added
Milestone: Sponsor F: March 15, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

Note: See TracTickets for help on using tickets.