Ticket #6407: 20120717-arma-server.txt

File 20120717-arma-server.txt, 6.5 KB (added by vmon, 7 years ago)

Conversation between vmon and arma about stegotorus as apache module

Line 
1<vmon> armadev: Why can't we have stegotorus as an apache module?
2<armadev> hmm. i'm not familiar enough with the server-side. are you arguing
3          for standalone proxy or for apache module?
4<vmon> If it is because of chop, I don't think chop is essential when we are
5       embeding the info into http content.
6<armadev> i haven't looked at the code, but i thought chop and http transport
7          were orthgonal
8<armadev> chop takes tor's flow and pulls off bytes. http transport is what
9          sends those bytes. chop decides how many should be sent. unless i'm
10          wrong.
11<vmon> Isn't chop there because tor packets are uniformly sized  [11:42]
12<armadev> yes
13<armadev> and because tor flows use a predictable number of tor cells
14          sometimes
15<vmon> but if we use http transport because each time we use different html or
16       other http object that they have different capacity  [11:43]
17<vmon> that objective would be met for free
18<vmon> I don't think we need chop
19<vmon> maybe if we are using obfs2 it might be necessary  [11:44]
20<armadev> is it possible for an adversary to look at the http connections and
21          guess how many bytes are encoded in them?
22<armadev> i think it depends how we do the embedding. in some cases likely
23          yes.  [11:45]
24<armadev> for example, with the embedding approaches described in the paper,
25          last time i saw it.
26<vmon> but if the adversary knows about embedding then we are defeated
27<vmon> Maybe the adversary model doesn't make sense  [11:46]
28<vmon> If the adversary knows that the http is fake then why it should look
29       any more
30<vmon> for size or something
31<armadev> i hope we're not defeated if the adversary knows about embedding. i
32          thought the goal was to make it hard to tell if a given http thing
33          he sees was embedded into, or just happened to be that way.
34<armadev> if the adversary can look at an http flow and say "*if* stegotorus
35          created this, it did it with 512 bytes of input", that is a good
36          hint that it was in fact a tor flow underneath  [11:47]
37<armadev> whereas with chop, we'd see a lot more false positives if the
38          adversary tries to guess whether it was created by stegotorus
39<vmon> I don't think size of original packets is any help to adversary to
40       detect that the http flow is coming from stegotorus.  [11:49]
41<vmon> The problem that chop emerged from was that when you only use tor
42       people can say which website you are visiting based on the size of the
43       packets  [11:50]
44<armadev> we'd have to ask zack. i hope that's not the case.
45<armadev> as for "I don't think size of original packets is any help to
46          adversary to detect that the http flow is coming from stegotorus.",
47          i claim it depends on how we do the embedding.  [11:51]
48<armadev> and with chop, it *shouldn't* depend on how we do the embedding.
49<vmon> ok so if it would be the case that your first statement is false then
50<vmon> is it plausable to have stegotorus server as an apache module?  [11:53]
51<armadev> plausible. what does it buy us?  [11:55]
52<armadev> also, why do you have to get rid of the chopper to make things an
53          apache module? can't the module just unchop too? or pass the traffic
54          to an unchopper?
55<vmon> "why do you have to get rid of the chopper" I don't think we have to do
56       that, I guessed that could be the reason that we need stand alone
57       server  [11:57]
58<vmon> and "what does it buy us?" simplicity  [11:58]
59<armadev> if obfsproxy server needed an apache, we wouldn't see many obfsproxy
60          servers  [11:59]
61<armadev> most people in the world don't have apache installed. so we give up
62          a lot by requiring it. that doesn't mean we shouldn't do it, but it
63          means we should hesitate.
64<vmon> correct but stegotorus needs the http cover, obfsproxy can works on its
65       own.  [12:00]
66<armadev> an argument in favor of an apache module is that it would make it
67          much easier for the server side to behave like apache  [12:01]
68<vmon> to some extent, though now I just get apache raw output and pass it by
69       so the content has no difference but it might be the timing no of
70       connection etc.  [12:02]
71<armadev> i was thinking error handling  [12:03]
72<armadev> and order of http headers in response
73<armadev> stuff like that
74<vmon> I think you are right  [12:04]
75<vmon> though still one can pass the request to apache and get the reply
76<vmon> but it's much more simple and more natural if you are just a module
77<vmon> in current setup you can have apache (or any other http server) on
78       another server if you the list of the files on the other server. 
79<vmon> may be we end up making two versions.  [12:09]
80<armadev> typically the best way to do that is to support one approach first,
81          and try to write it so supporting the other one next isn't so hard
82<armadev> if you start out trying to support both, you may not finish either
83<karsten> gsathya: sure, postgres would work. want to design a db schema for
84          the current data? happy to review it and give feedback.  [12:10]
85<vmon> I'm sticking to the current model (stand alone) for now.
86<armadev> vmon: makes sense. you should record somewhere the fact that you
87          thought about this. for example, in the todo file or in a trac
88          ticket ("investigate moving more of the stegotorus server into an
89          apache module")  [12:14]
90<vmon> OK I'll do it  [12:15]
91<vmon> I'll leave a note on github
92<armadev> ah. stegotorus isn't a component in tor's trac. i wonder if we
93          should fix that.  [12:16]
94<vmon> but what do you think about the fact that if it's a module then it
95       won't have any of part that deal with server in network.cc
96<vmon> it makes it much simpler
97<vmon> less error
98<vmon> I just want to say it's also an influencial part  [12:17]
99<vmon> "stegotorus isn't a component in tor's trac. i wonder if we  [12:18]
100<vmon>           should fix that." probably but we thought we can spend time
101       on more important stuff. github has some kind of TODO list
102<armadev> please do make a ticket. but i agree with zack that you shouldn't
103          derail the summer plans to switch to an apache module. also, the
104          ticket might be "investigate tradeoffs with using an apache module",
105          since it's far from clear that it's the best plan.
106<armadev> you should also read nickm's proposal 203 for a related topic. not
107          quite the same, but might give you useful ideas.  [16:02]
108<vmon> armadev: I was thinking of having both model along  [16:15]
109<vmon> each other