Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:05:18Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21179Add a fuzzing harness for the tor OR protocol2020-06-13T15:05:18ZteorAdd a fuzzing harness for the tor OR protocolTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13508Add messaging protocol that is resistant to traffic analysis2020-06-13T14:39:42ZTracAdd messaging protocol that is resistant to traffic analysisThis is a proposal to add a messaging protocol that is resistant to traffic analysis. The protocol would allow a message of reasonable length to be sent to a relay, which would then store the message for a variable period of time before...This is a proposal to add a messaging protocol that is resistant to traffic analysis. The protocol would allow a message of reasonable length to be sent to a relay, which would then store the message for a variable period of time before forwarding to the next relay in the circuit. Circuits would be built using the message store-and-forward protocol to send setup messages, including circuits to and from Tor hidden service rendezvous points. The variable delay time could potentially be programmed by the client in the message wrapper.
Clients could take advantage of this protocol (including Tor hidden services) to implement messaging clients that are resistant to traffic analysis, i.e., the variable delay between the time messages are received and sent would make it vastly more difficult to determine the endpoints of a message by observing the packets being sent between a set of relays. This protocol would not be suitable for "realtime" applications such as web browsing and voice or video communication; it would only be suitable for text messages, file transfer and similar non-realtime applications.
**Trac**:
**Username**: AlanTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15243Allow multiple Tor instances to share directory info, guards, and who knows w...2020-06-13T14:47:04ZNick MathewsonAllow multiple Tor instances to share directory info, guards, and who knows what else?Frequently people want applications to run in a one-tor-per-app model. Sometimes, people want systems to run in a one-tor-per-user model. The main problem here is that some information (like choice of guards) should be consistent acros...Frequently people want applications to run in a one-tor-per-app model. Sometimes, people want systems to run in a one-tor-per-user model. The main problem here is that some information (like choice of guards) should be consistent across all Tors, and some effort (like fetching directory information) is needlessly duplicated across all Tors.
We should look for designs that fix this.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15213DNS tunneling transport (like iodine, dnscat)2020-06-13T18:35:10ZFederico Cerattofederico.ceratto@gmail.comDNS tunneling transport (like iodine, dnscat)DNS-based pluggable transport.
Encode data in recursive DNS queries and responses. Your local recursive resolver sends your packets to the right place. A DNS bridge would be an authoritative name server for a particular domain; users wo...DNS-based pluggable transport.
Encode data in recursive DNS queries and responses. Your local recursive resolver sends your packets to the right place. A DNS bridge would be an authoritative name server for a particular domain; users would configure a domain rather than an IP address in their Bridge lines. Tools already exist to do DNS tunneling, for example iodine and dnscat. Probably requires a reliability layer and periodic polling by the client.
Provides a way for users behind restrictive firewalls to connect to Tor at the expense of speed.
Mailing list discussions:
[tor-dev] obfsproxy dns transport
https://lists.torproject.org/pipermail/tor-dev/2014-February/006250.html (Feb 2014)
using OzymanDNS to access Tor via DNS
https://lists.torproject.org/pipermail/tor-talk/2006-January/007124.html (Jan 2006)https://gitlab.torproject.org/legacy/trac/-/issues/14209Implement SOCKSPort windows:path for named pipes2020-06-13T16:09:26ZTracImplement SOCKSPort windows:path for named pipesThis is identical to #12585 SocksSocket except for Windows users wishing to use Named Pipes in this same manner.
Firefox changes to use this (instead of SocksPort) unknown. See https://bugzilla.mozilla.org/show_bug.cgi?id=892114
**Trac...This is identical to #12585 SocksSocket except for Windows users wishing to use Named Pipes in this same manner.
Firefox changes to use this (instead of SocksPort) unknown. See https://bugzilla.mozilla.org/show_bug.cgi?id=892114
**Trac**:
**Username**: anonTor: unspecified