Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2020-06-27T13:44:07Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7167Combine traffic obfuscation with address diversity of flash proxy2020-06-27T13:44:07ZKarsten LoesingCombine traffic obfuscation with address diversity of flash proxy(Quoting text written by David Fifield for this ticket description.)
Find out what current DPI capabilities are with respect to WebSocket, at least through product literature.
Find out what existing, popular, WebSocket applications are...(Quoting text written by David Fifield for this ticket description.)
Find out what current DPI capabilities are with respect to WebSocket, at least through product literature.
Find out what existing, popular, WebSocket applications are used (chat, video, games?) that will be collateral damage to block. Write a short report on 1) how common they are, and 2) what their traffic looks like.
Implement a transport with an obfs2 stream transported over WebSocket.
We can imagine a new "obfs2-in-websocket" transport, but it might be a better design to allow chaining of proxies that don't necessarily have to know about one another. So you might have something like this on the client:
```
ClientTransportPlugin websocket socks4 127.0.0.1:9001
ClientTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --managed
Bridge obfs2|websocket 0.0.1.0:1
```
On the server:
```
ServerTransportPlugin websocket proxy 127.0.0.1:9901
ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --managed
# And then some new configuration to say that things received on
# port 9901 need to be forwarded to the local obfsproxy port.
# Port 9901 won't be able to be used for plain websocket
# connections, and I guess this will have to be reflected in the
# descriptor somewhere.
```
A client tor can probably managed these chained proxies using SOCKS-in-SOCKS. There's a brief note on chaining proxies here: https://trac.torproject.org/projects/tor/ticket/2841#comment:12
See what other obfuscation possibilities exist. I don't think that TLS-wrapped WebSockets work for us (http://archives.seul.org/or/talk/Oct-2012/msg00190.html), but I haven't thought about it exhaustively. Replacing WebSocket with HTTP requests (the flash proxy POSTs bodies to both the client and the relay, and receives response bodies) would likely work, and would allow fuller control of the payloads (whereas with WebSocket we cannot escape the WebSocket framing). We gave up on using Flash, but Flash sockets allow us to control exactly what goes on the wire, except for an initial cross-domain request.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/7153Don't require pluggable transport proxies to be SOCKS proxies2021-06-17T14:30:51ZKarsten LoesingDon't require pluggable transport proxies to be SOCKS proxies(Re-using text from Zack Weinberg for this description.)
There are pluggable transport proxies that don't actually act as a SOCKS proxy. For example, StegoTorus has its own configuration; it ignores everything told it in the SOCKS dial...(Re-using text from Zack Weinberg for this description.)
There are pluggable transport proxies that don't actually act as a SOCKS proxy. For example, StegoTorus has its own configuration; it ignores everything told it in the SOCKS dialogue and always connects to the bridge that it knows about. If you want multiple StegoTorus bridges accessible to your Tor client, you need multiple `"ClientTransportPlugin ... exec"` specifications. This is only going to get worse when they move away from having everything set up on StegoTorus' command line, which has been direly needed for some time now.
Theoretically all of StegoTorus' configuration _could_ be encapsulated in the SOCKS key-value-pairs-in-the-password hack that's described in 180-pluggable-transport.txt, but they never implemented that and they don't want to. They want to rip out all of the SOCKS code, in fact. The way they want it to work is
```
Bridge storus1 direct [keyid=...]
ClientTransportPlugin storus1 direct 127.0.0.1:8888
```
In this case, `'storus1'` is *not* a "method", it's a human-readable identifier for the bridge that Tor will be connected to if it starts talking the OR protocol -- with no initial SOCKS exchange! -- on 127.0.0.1:8888.
`"direct"` should also be valid in CMETHOD/SMETHOD lines for the proxy-management protocol, with the same semantics. Zack says he hasn't really thought through how the server side of this stuff ought to work.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5614Develop an experimental Python pluggable transport library2020-06-27T13:44:07ZKarsten LoesingDevelop an experimental Python pluggable transport libraryIn sponsor F year 2 deliverable 19 (legacy/trac#5549) we concluded that writing a Python pluggable transport library is feasible. This ticket is about the actual development of an experimental Python library for pluggable transports. D...In sponsor F year 2 deliverable 19 (legacy/trac#5549) we concluded that writing a Python pluggable transport library is feasible. This ticket is about the actual development of an experimental Python library for pluggable transports. Deliverable 19 says "If we decide it's smart, get it started," but it doesn't make any promises how far we'll get. That's why this is a sponsor Z deliverable that isn't tied to the sponsor F milestone in November.
George outlined a few possible next steps (which should probably become child tickets soon):
- George knows a couple of people who are coding Python pluggable transports; one of them is wiretapped with banana phone, another one is the Portland university guys. He wants to prepare a pluggable transport library for them. Roger adds that flash proxy also has a Python part. In general, Roger thinks that looking at other Python pluggable transports and trying to help them all use our framework should be part of this deliverable.
- George thinks that most of the future transports we are thinking of can be handled (performance-wise) by a Python program. He wants to prepare an obfs2-like thing and benchmark it by feeding it with thousands of connections. George wants to see how many of them it will handle (he expects _many_).
- George also wants to prepare a very lite managed proxy library, which will read environment variables etc. He also wants to write a very simple pluggable transport in Python which will use that managed proxy library.
- George wants to evaluate py2exe (and the other similar things).
Here are a few more random notes which seem relevant:
- Nick suggests that we could do something minimalistic with twisted. George hopes to be able to use all the other web protocols baked in twisted for transports.
- George will try to learn the truth about bytearrays and cryptographic material overwriting. The idea is that by using bytearrays in Python one can actually overwrite cryptographic material "securely".George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5549Evaluate feasibility of a Python obfsproxy and possibly get it started2020-06-27T13:44:07ZKarsten LoesingEvaluate feasibility of a Python obfsproxy and possibly get it startedItem 19 from [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2) is: "evaluate feasibility of a python equivalent to obfsproxy, to make it easier for people to write transports in python. See also Brandon Wiley's "dust". If we dec...Item 19 from [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2) is: "evaluate feasibility of a python equivalent to obfsproxy, to make it easier for people to write transports in python. See also Brandon Wiley's "dust". If we decide it's smart, get it started."
There are a few substeps here: first, we should discuss feasibility of a Python obfsproxy; maybe we need some proof-of-concept implementation to further evaluate things we cannot solve by discussion; then we need to make a decision; and finally, if we decide that having a Python obfsproxy is a good idea, we'll have to get it started.
Creating a child ticket for the discussion part. Further substeps should get their own child tickets.
We need to decide whether this is a July or November deliverable (optimistically assigning to July), and we need somebody to lead the deliverable.
There are quite a few people who I've heard might be interested in this topic and who I'm cc'ing: nickm, asn, aagbsn, blanu, zwol, xmux. If more people are interested, please cc yourself.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5483managed pluggable transports should be able to pause Tor's circuit-building?2021-06-17T14:27:44ZRoger Dingledinemanaged pluggable transports should be able to pause Tor's circuit-building?Hooman with his Skypemorph transport (http://archives.seul.org/tor/dev/Mar-2012/msg00093.html) notes that when Tor first starts, and starts his transport, it takes his transport a minute or two to become ready. During that time, Tor trie...Hooman with his Skypemorph transport (http://archives.seul.org/tor/dev/Mar-2012/msg00093.html) notes that when Tor first starts, and starts his transport, it takes his transport a minute or two to become ready. During that time, Tor tries to start a circuit to his configured bridges, times out the circuit, and marks his bridges down.
He can work around the problem in his experiments by starting Tor with "DisableNetwork 1" in the torrc, and when he's ready, remove the line and hup tor. That's not a good solution for real users though.
The problem would be less pronounced for him if Tor had better handling of when to mark a bridge down. There are a variety of tickets about that. But I think those issues are different from this ticket.
Perhaps the various proposals we've been writing recently have some opportunity to fit this in? Which ones are the best ones to look at?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5148SIGHUP managed proxies when logs reopened2021-10-07T14:21:00ZtwildeSIGHUP managed proxies when logs reopenedWe use SIGHUP to cause Tor to reopen its logs after a rotation, but currently this SIGHUP is not passed along to a managed proxy (ie obfsproxy). The only way to automatically tell obfsproxy to reopen logs without finding its process and...We use SIGHUP to cause Tor to reopen its logs after a rotation, but currently this SIGHUP is not passed along to a managed proxy (ie obfsproxy). The only way to automatically tell obfsproxy to reopen logs without finding its process and sending a SIGHUP manually is to do a full tor restart, which will kill and restart the managed proxy as well. Perhaps all SIGHUPs to Tor should just be passed along to any (unchanged argument) managed proxies?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5143ServerTransportPlugin sets or_port to '127.0.0.1:0'2020-06-27T13:44:08ZTracServerTransportPlugin sets or_port to '127.0.0.1:0'When Tor is configured with
ORPort "[::]:9001" so on default linux it is configured
to listen on both v4 and v6 sockets.
and obfsproxy configured to run in managed mode:
ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --log...When Tor is configured with
ORPort "[::]:9001" so on default linux it is configured
to listen on both v4 and v6 sockets.
and obfsproxy configured to run in managed mode:
ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --log-min-severity=debug --no-safe-logging --logfile=/var/log/tor/obfsproxy.log --managed
we get:
Proxy environment:
[...]
or_port: '127.0.0.1:0'
[...]
If we add a v4 only OrPort
OrPort "0.0.0.0:9001"
it works as expected:
[...]
or_port: '127.0.0.1:9001'
[...]
**Trac**:
**Username**: murbleGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5059Organize an obfsproxy/PTTB test run2020-06-27T13:44:08ZGeorge KadianakisOrganize an obfsproxy/PTTB test runkarsten and arma were considering an obfsproxy testrun, where a
client-PTTB (legacy/trac#4927) would be deployed, configured with hardcoded
obfs2'ed bridges.
This should get us some bug reports on obfsproxy, some usability
comments from...karsten and arma were considering an obfsproxy testrun, where a
client-PTTB (legacy/trac#4927) would be deployed, configured with hardcoded
obfs2'ed bridges.
This should get us some bug reports on obfsproxy, some usability
comments from end-users, and help us figure out legacy/trac#5038 and other
performance-related questions.
The initial plan was to setup an obfsproxy in moria, but I believe
it's a better idea to setup obfsproxy in less sensitive boxes [0].
This is a ticket to coordinate this effort.
legacy/trac#5047 is also important, to gather statistics and see approximately
how many users used pluggable transports during the testing period.
We should also decide how many bridges to hardcode. Do we actually
need more than one? I know that gamambel, marlowe and ln5 are
interested in setting up obfsproxy. Still, I think that the original
idea of a single bridge is better, so that we can get better answers
for legacy/trac#5038. If too many users use the bundle, we can then add more
bridges. So, who gets to setup the PTTB obfsproxy?
[0]:
There are probably easier ways of compromising computers than
exploiting obfsproxy security bugs, but I will be feeling better if
obfsproxy-beta is not touching a directory authority.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5023Morpher pluggable transport: Select algorithm for packet size morphing2020-06-27T13:44:08ZGeorge KadianakisMorpher pluggable transport: Select algorithm for packet size morphingThis is a ticket to resolve a) of comment:1:ticket:4680 :
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 hav...This is a ticket to resolve a) of comment:1:ticket:4680 :
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.
I stupidly attached all relevant files to legacy/trac#4680, but let's continue the discussion here to avoid flooding legacy/trac#4680 more.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5012Write proposals to allow an external program that discovers bridge addresses ...2020-06-27T13:44:08ZKarsten LoesingWrite proposals to allow an external program that discovers bridge addresses to tell Tor about them and start implementing the proposalsThis ticket is part of sponsor F deliverable 7. Once we have a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to write proposals and start implementing them. The "and start ...This ticket is part of sponsor F deliverable 7. Once we have a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to write proposals and start implementing them. The "and start implementation as needed" part of the deliverable text is vague enough to focus on the design discussion and proposals. If there's time left to implement something, great, but if not, that's fine, too. We can still implement proposals between March and November 2012.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5011Discuss possible designs for an external program that discovers bridge addres...2020-06-27T13:44:08ZKarsten LoesingDiscuss possible designs for an external program that discovers bridge addresses to tell Tor about themThis ticket is part of sponsor F deliverable 7. Before we can come up with a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to discuss possible designs.
Mike said he's going...This ticket is part of sponsor F deliverable 7. Before we can come up with a recommended approach for an external program that discovers bridge addresses to tell Tor about them, we need to discuss possible designs.
Mike said he's going to take the lead on the discussion. Back in December we agreed on February 13 as the deadline for the discussion. Maybe we need a new deadline, but one that still leaves time for writing proposals and starting to implement them.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/5010Come up with a recommended approach for an external program that discovers br...2020-06-27T13:44:08ZKarsten LoesingCome up with a recommended approach for an external program that discovers bridge addresses to tell Tor about themSponsor F deliverable 7 says: "pluggable transports: Come up with a recommended approach for an external program that discovers bridge addresses to tell Tor about them. Does it tell Vidalia, which setconfs them? Should it be a Vidalia pl...Sponsor F deliverable 7 says: "pluggable transports: Come up with a recommended approach for an external program that discovers bridge addresses to tell Tor about them. Does it tell Vidalia, which setconfs them? Should it be a Vidalia plugin, or launched by Vidalia? Or can we integrate it into Torbutton? Or should it be a separate program and talk the controller protocol itself? Should we extend the stdin/stdout PT protocol? Or should the separate program just be an independent proxy, and never even tell Tor about the bridges? I am thinking in particular of the ISC program that will take in an n-tuple from a rendezvous service and output some bridge addresses, but it would be good to have a plan for future similar tools. Write proposals and start implementation as needed. [Nick, George, Tomas, Mike, Roger, everybody]"
Mike and I decided to split this deliverable into two substeps:
- Discuss possible designs.
- Write proposals and start implementing them.
Assigning this project ticket to Mike. He said he's fine taking the lead on the discussion task, but not on the proposal writing task. Hopefully the discussion will give us some hints who could write the proposals and start implementing them.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/4685Design and implement further pluggable transport extensions2020-06-27T13:44:08ZKarsten LoesingDesign and implement further pluggable transport extensions[Sponsor F deliverable 4](uploads/org/sponsors/SponsorF/Year1) is about designing and implementing further pluggable transport extensions. The original deliverable text is: "further extensions as needed from the Tor perspective for plug...[Sponsor F deliverable 4](uploads/org/sponsors/SponsorF/Year1) is about designing and implementing further pluggable transport extensions. The original deliverable text is: "further extensions as needed from the Tor perspective for pluggable transport (proposal 180) support."
Quoting Roger here for more background: "Basically, we should make sure Tor is ready for whatever people are going to try to do with pluggable transports. Make Tor implement the pluggable transport spec, and make sure the spec is what we thought it should be. And guess what people will want it to be in the future so we're ready for that. And if somebody tries to use it for some of that future stuff, make it work for that."
Note that there's an overlap between this deliverable and the [sponsor G milestone in June 2012](uploads/org/sponsors/SponsorG#Phase3:June302012) where we promised to finish the coding on Tor, obfsproxy, BridgeDB et al. to make pluggable transports work with obfs2 as proof-of-concept transport. The current plan is to finish the Tor coding until March 15, 2012 for this deliverable and the coding on obfsproxy and BridgeDB until June 30, 2012 for the sponsor G deliverable (legacy/trac#4566, legacy/trac#4567, legacy/trac#4568).
This ticket gets auto-assigned to George. Not sure if Nick should lead this deliverable, because George already leads all the other pluggable transport deliverables for sponsor G.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/4680Design, build, and document Morpher as a pluggable transport2020-06-27T13:44:08ZKarsten LoesingDesign, build, and document Morpher as a pluggable transportFor [sponsor F deliverable 8](uploads/org/sponsors/SponsorF/Year2#8) we promised to work on a pluggable transport based on traffic morphing as described in this UNC [paper](http://freehaven.net/anonbib/#morphing09). The name of this plu...For [sponsor F deliverable 8](uploads/org/sponsors/SponsorF/Year2#8) we promised to work on a pluggable transport based on traffic morphing as described in this UNC [paper](http://freehaven.net/anonbib/#morphing09). 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.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/4679Design a pluggable transport roadmap2020-06-27T13:44:09ZKarsten LoesingDesign a pluggable transport roadmap"Disambiguation" note: This ticket is about comparing pluggable transport protocols, not about writing down the steps for deploying pluggable transports (legacy/trac#4562).
For [sponsor F deliverable 6](uploads/org/sponsors/SponsorF/Yea..."Disambiguation" note: This ticket is about comparing pluggable transport protocols, not about writing down the steps for deploying pluggable transports (legacy/trac#4562).
For [sponsor F deliverable 6](uploads/org/sponsors/SponsorF/Year2#6) we promised to "help SponsorF design a roadmap for the scope of transports we expect need work." This deliverable comprises the following tasks:
* Talk to SponsorF about the prototypes of various pluggable transports they came up with and include them in the roadmap.
* Describe what security properties each of the transports aims to provide (i.e. what censorship techniques it aims to defeat).
* Figure out how far along we are at each of them and what research and development roadblocks remain.
* Prioritize transports by complexity and urgency of deployment.
* Build a plan for how to compose transports appropriately without screwing up their properties.
* For each transport, speculate about how easy and/or smart it would be to bake into Tor itself.
Optimistically assigning this ticket to Steven, because he said he might be able to lead this deliverable. This deliverable needs input from many Tor developers.Steven MurdochSteven Murdochhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/4562Write a pluggable transport deployment roadmap2020-06-27T13:44:09ZKarsten LoesingWrite a pluggable transport deployment roadmapThis ticket is about coming up with a plan for making pluggable transports work in practice, including how to solve the packaging and updating problems. The output document will describe ways for rolling out new protocols in the future,...This ticket is about coming up with a plan for making pluggable transports work in practice, including how to solve the packaging and updating problems. The output document will describe ways for rolling out new protocols in the future, even though the initial deployment will only contain obfs2 as transport. The document will also cover how BridgeDB will give out transport information to bridge users. Basically, the document will describe what users will have to do to use pluggable transports: download a special bundle, learn bridges that support one or more pluggable transports, put the Bridge lines into the torrc or Vidalia, done. The document will also describe how Tor uses UPnP to set up port forwarding to the bridge proxy.
This ticket is part of the March 31, 2012 milestone for sponsor G.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/4557Write a proposal to add basic pluggable transport support to Tor2020-06-27T13:44:09ZKarsten LoesingWrite a proposal to add basic pluggable transport support to TorWe have [proposal 180](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt) which describes a way to decouple protocol-level obfuscation from the core Tor protocol in order to better resist client-b...We have [proposal 180](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt) which describes a way to decouple protocol-level obfuscation from the core Tor protocol in order to better resist client-bridge censorship. The pluggable transport support doesn't need to be feature-complete (whatever that means), but should be sufficient to support basic proxies and transports.
This document will be part of the December 31, 2011 milestone for sponsor G.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/3591We must implement the whole pluggable transports thing2021-06-11T14:59:17ZGeorge KadianakisWe must implement the whole pluggable transports thingThis is the master ticket for all pluggable transports implementation tickets.
(It contains tickets both for tor and obfsproxy.)
[[TicketQuery(parent=legacy/trac#3591,format=table,col=component|owner|summary|priority,order=priority)]]This is the master ticket for all pluggable transports implementation tickets.
(It contains tickets both for tor and obfsproxy.)
[[TicketQuery(parent=legacy/trac#3591,format=table,col=component|owner|summary|priority,order=priority)]]https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/3578180-pluggable-transport.txt changes2020-06-27T13:44:09ZGeorge Kadianakis180-pluggable-transport.txt changesWhile implementing 180-pluggable-transport.txt, I changed a couple of things in the spec.
You can find the changes I made so far in 'proposal_180' branch in my git://gitorious.org/torspec/torspec.git repo.
Comments are most welcome :)
...While implementing 180-pluggable-transport.txt, I changed a couple of things in the spec.
You can find the changes I made so far in 'proposal_180' branch in my git://gitorious.org/torspec/torspec.git repo.
Comments are most welcome :)
PS: Hope this is the correct category for this.George KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/trac/-/issues/2860Research TCP connection patterns produced by web browsing2021-06-17T14:17:38ZRobert RansomResearch TCP connection patterns produced by web browsingWe suspect that Tor connections (and other TCP-based encrypted tunnel connections) can easily be distinguished from connections produced by a web browser by an attacker who has only logs of TCP SYN, FIN, and RST packets and the times at ...We suspect that Tor connections (and other TCP-based encrypted tunnel connections) can easily be distinguished from connections produced by a web browser by an attacker who has only logs of TCP SYN, FIN, and RST packets and the times at which they were sent. We should research this further.
The first step is to collect example recordings of the SYN, FIN, and RST packets produced by:
* a normal Tor client,
* a Tor client configured to use one bridge,
* a Tor client configured to use ten bridges,
* Firefox loading a simple (one HTML page without CSS or JS) web page over HTTPS,
* Chromium loading the same simple web page,
* Firefox viewing a JS-intensive web page (over HTTPS if possible), and
* Chromium viewing the same JS-intensive web page.
A simple visualization tool for the recordings will also be needed.Brandon WileyBrandon Wiley