Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:13:02Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1748Implement microdescriptors2020-06-13T14:13:02ZNick MathewsonImplement microdescriptorsMicrodescriptors are a feature designed to greatly reduce the amount of data that needs to be transmitted to implement the Tor directory protocol. See [proposal 158 "Microdescriptors"](https://gitweb.torproject.org/tor.git/blob_plain/HE...Microdescriptors are a feature designed to greatly reduce the amount of data that needs to be transmitted to implement the Tor directory protocol. See [proposal 158 "Microdescriptors"](https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/proposals/158-microdescriptors.txt) and [proposal 162 "Publish the consensus in multiple flavors"](https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/proposals/162-consensus-flavors.txt) for design details.
There's an initial implementation at the server level (authorities generate microdescriptors and the appropriately flavored consensus).
We need to implement the remaining server and client components for May 1 2011.Deliverable-May2011Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1749Split relay and link crypto across multiple CPU cores2020-06-13T17:46:34ZNick MathewsonSplit relay and link crypto across multiple CPU coresRight now, Tor does nearly all of its work in one main thread. We have a basic "CPUWorker" implementation that we use for doing server-side onionskin crypto in a separate thread, but thanks to improvements long ago, server-side onionski...Right now, Tor does nearly all of its work in one main thread. We have a basic "CPUWorker" implementation that we use for doing server-side onionskin crypto in a separate thread, but thanks to improvements long ago, server-side onionskin crypto on longer dominates. If we could split the work of relay AES-CTR crypto and SSL crypto across multiple threads, that would be pretty helpful in letting high-performance servers saturate their connections. (Blutmagie has wanted this for some while.)
Child Tickets:
[[TicketQuery(parent=#1749)]]Tor: unspecifiedChelsea KomloChelsea Komlohttps://gitlab.torproject.org/legacy/trac/-/issues/1752Make it easier for everybody to be a bridge2020-06-13T14:05:25ZNick MathewsonMake it easier for everybody to be a bridgeOur bridges design requires lots of bridges, but configuring a bridge is currently a nontrivial activity. It would be great if more clients could act as bridges automatically.
There's an initial start of a design under [proposal idea x...Our bridges design requires lots of bridges, but configuring a bridge is currently a nontrivial activity. It would be great if more clients could act as bridges automatically.
There's an initial start of a design under [proposal idea xxx-automatic-node-promotion.txt](https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt).
Child Tickets:
[[TicketQuery(parent=#1752)]]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1753Make windows relays more reliable2020-06-13T14:05:25ZNick MathewsonMake windows relays more reliableAccording to current analysis, the mean uptime for a relay running on Windows XP is 10 hours. We should figure out what, if anything, we can do to solve that.
Child tickets:
[[TicketQuery(parent=#1753)]]According to current analysis, the mean uptime for a relay running on Windows XP is 10 hours. We should figure out what, if anything, we can do to solve that.
Child tickets:
[[TicketQuery(parent=#1753)]]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1849Optimistic Data for Tor2020-06-13T16:08:56ZRoger DingledineOptimistic Data for TorIan has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea.
[https://thunk.cs.uwaterloo.ca/optimisti...Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea.
[https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf](https://web.archive.org/web/20170515183058/https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf)
As I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
D) Set up a Torperf variant that uses optimistic data, and compare performance results for various web browsing patterns.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1851Learn which bridges can't reach baidu2020-06-13T17:46:44ZRoger DingledineLearn which bridges can't reach baiduI hear from our friends at GIFC that when their bridges get blocked, they get blocked duplex. That is, people in China can't reach the bridge, but also the bridge can't reach China. So one trick they have for checking if bridge addresses...I hear from our friends at GIFC that when their bridges get blocked, they get blocked duplex. That is, people in China can't reach the bridge, but also the bridge can't reach China. So one trick they have for checking if bridge addresses need to be rotated is pinging a well-known site inside China.
Now, this reachability testing won't solve all our problems. In practice, we know from #1728 that sometimes the gfw blocks our bridges much more precisely by ip:port rather than by blackholing the IP address.
On the other hand, we know that at least in the Sept 2009 blocking event, they blocked some bridges by ip:port and others by blackholing them:
http://archives.seul.org/tor/relays/Sep-2009/msg00003.html
So it would be worthwhile to teach bridges how to check if they've been blackholed, in case it turns out to be useful trick in the arsenal.
Step one is to come up with a proposal for how we're going to check. Should we just fetch the baidu frontpage at irregular times, and if we've failed too many tests lately but we otherwise seem to have a working network connection, add a line to our extra-info descriptor? What are the blocking-resistance implications of having all our bridges voluntarily touch baidu periodically?
Step 1.5 is to implement the proposal.
Step two is to run a few bridges ourselves, get them blackholed (perhaps by giving out their addresses in every single answer on bridgedb ;), and test to make sure the reporting behavior is working as expected.
Step three is to look for patterns in the extra-info descriptors that the bridge directories aggregate. Do the bridges that seem to have no traffic from China report that they can't reach Baidu? Corroborate by doing direct scans from inside China.
Step n, as a bonus, is to evaluate whether we want to get any more methodical about which domains we test. Maybe have a list of domains somewhere that bridges learn that we can update on the fly? We should save this question until we've at least finished step two.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1853Develop bridge image for the cloud2012-02-28T00:21:11ZRoger DingledineDevelop bridge image for the cloudWhen we first started working on the bridge design, we were thinking to ourselves "we should get lots of bridges, so China can't block them all." That was wrong. Instead we should be thinking "we should make sure the rate of getting new ...When we first started working on the bridge design, we were thinking to ourselves "we should get lots of bridges, so China can't block them all." That was wrong. Instead we should be thinking "we should make sure the rate of getting new bridge addresses exceeds the rate that China can block them." The key resource that bridges need is changeable IP addresses. So we should experiment with easy-to-set-up images for the cloud, so people can pop up a bridge, and then discard it once it gets blocked.
Step one is to set up a bridge on the cloud (say, Amazon) and run it for a little while, to make sure there aren't any stupid things making this harder than it sounds.
Step two is to learn more about the pricing structures: is baseline time cheap but bandwidth is expensive? Or CPU? Etc. How much money are we talking here, for a variety of bridge scenarios? Evaluate a variety of cloud providers.
Step three, investigate programmatic "get new IP address" cloud functions we can use. In the future (e.g. #1851 or others), bridges will be able to automatically discover that they need a new IP address. The crude approach would be to abandon the bridge image and start up another one next door. The better approach would be to teach Tor how to press the "new IP address please" button on its host.
Step four is to learn more about automation. What are the steps for making it so you can tell other people "just launch image Z and you'll be running a bridge"? Do these steps and make it so.
Step five is to write the howto for groups like RFA who want to ask people to run bridges for them. Make sure to resolve usability pieces like "should my bridges publish in bridgedb or not".Deliverable-Mar2011https://gitlab.torproject.org/legacy/trac/-/issues/1855Compare datagram Tor designs2020-06-13T14:06:03ZRoger DingledineCompare datagram Tor designsA popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.
We've be...A popular topic over the years has been moving from TCP transport between Tor relays to UDP transport, and then maybe switching to some congestion control approach that better recognizes the real endpoints in the communication.
We've been talking to Robert Watson and Bjoern A. Zeeb of the FreeBSD project about helping to fund them to port the FreeBSD network stack to user-space. Lately the user-space networking stack has seemed like the primary stumbling block.
We really ought to have a better intuition about what we're going to actually *do* once that stumbling block is resolved.
We should write a draft design doc and spec for a future version of Tor based on UDP transport. One main goal is to identify areas of uncertainty that need to be solved before such a system can be built and deployed. Another aspect of that goal is to identify and flesh out unsolved research questions, and pros and cons to various tradeoffs that designs like this have made. For example, should we do TCP-over-UDP pairwise, or end-to-end? Various research groups have very strong feelings, and often their recommendations conflict.
We might draw on six pieces of background work for ideas:
1) Joel Reardon's thesis:
http://freehaven.net/anonbib/#reardon-thesis
2) The old ZKS designs:
http://freehaven.net/anonbib/#freedom2-arch
3) Zach Brown's Cebolla:
http://freehaven.net/anonbib/#cebolla
http://www.cypherspace.org/cebolla/
4) Camilo Viecco's UDP-Tor design:
http://www.petsymposium.org/2008/hotpets/udp-tor.pdf
5) Csaba Kiraly's work:
http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf
6) Marc Liberatore's proposal 100:
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/100-tor-spec-udp.txt
7) SHALON: Lightweight Anonymization based on Open Standards by Panchenko et al:
http://lorre.uni.lu/~andriy/papers/shalon-icccn09.pdf
The design should be sure to include a transition plan, and a plan for how to let clients who need blocking-resistance (e.g. they need to look like SSL on the wire) continue to use the network.Tor: unspecifiedSteven MurdochSteven Murdochhttps://gitlab.torproject.org/legacy/trac/-/issues/1865Implement Isolated Streams Proposal (171)2020-06-15T23:13:22ZRobert HoganImplement Isolated Streams Proposal (171)Implement the proposal at:
http://archives.seul.org/or/dev/Jul-2010/msg00021.html
Work in progress at:
https://gitweb.torproject.org/hoganrobert/tor.git/shortlog/refs/heads/isolatestreamsImplement the proposal at:
http://archives.seul.org/or/dev/Jul-2010/msg00021.html
Work in progress at:
https://gitweb.torproject.org/hoganrobert/tor.git/shortlog/refs/heads/isolatestreamsTor: 0.2.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/2473Develop a design to support multiple bridge authorities2020-06-13T14:08:30ZRoger DingledineDevelop a design to support multiple bridge authoritiesThe main thing blocking multiple bridge directory authorities right now is that we don't have a design for how it would work. For the normal directory authority design, we want all of them to know about all relays. But for bridge authori...The main thing blocking multiple bridge directory authorities right now is that we don't have a design for how it would work. For the normal directory authority design, we want all of them to know about all relays. But for bridge authorities, that would defeat the purpose. So we want some algorithms for distributing bridges over authorities, such that bridge users know where to go to look up a given bridge (probably as a function of its identity fingerprint). Perhaps the algorithm should provide stable answers even as we change the set of bridge authorities, and for clients and bridges running a variety of Tor versions. More generally, we need to figure out what functionality we want and what security properties we should shoot for.
Somebody should start with a proposal, and go from there.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2552help tor2web work better2020-06-13T14:08:44ZRoger Dingledinehelp tor2web work bettertor2web complains of abysmal performance on (some) hidden services. Helping them improve their performance and stability could be a good way to better understand what's going wrong with hidden services. Plus it will help them popularize ...tor2web complains of abysmal performance on (some) hidden services. Helping them improve their performance and stability could be a good way to better understand what's going wrong with hidden services. Plus it will help them popularize the overall concept.
I'm going to use this as the catch-all trac ticket for the topic.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2628Be smarter about launching connections to authorities to learn about clock skew2020-06-13T15:51:59ZNick MathewsonBe smarter about launching connections to authorities to learn about clock skewWhile applying altf4's code related to bug1074, some possible enhancements came up. They wouldn't be too hard to do.
Right now, we notice clock skew for two reasons: a time from a netinfo cell is different from ours, and a time in an H...While applying altf4's code related to bug1074, some possible enhancements came up. They wouldn't be too hard to do.
Right now, we notice clock skew for two reasons: a time from a netinfo cell is different from ours, and a time in an HTTP response header is different from ours. In the netinfo case, if the skew came from an authority, we believe it. If not, and we haven't gotten a netinfo from an authority, we launch an OR connection to an authority.
In fact, we should be a bit more sophisticated:
* Any authenticated time from an authority should count as "hearing the time from an authority". This includes not only netinfo cells but also authenticated directory connections.
* Maybe, skew information from regular HTTP responses should also count as "hearing that we are skewed from a non-authority".
* Instead of keeping track of *whether* we've heard the correct time from an authority, we should keep track of *when* we heard from the authority. In other words, if we last heard about the correct time from an authority an hour ago and somebody else disagrees with them, the authority is probably right. But if we last heard about the correct time a week ago, we might want to ask again.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2769Experiments and Data for Tor Performance Tech Report2020-06-13T17:46:49ZMike PerryExperiments and Data for Tor Performance Tech ReportKarsten and I intend to write a tech report covering the use of TorPerf and other metrics to measure tor network performance, and to determine if certain performance tweaks results in improved or degraded performance. This is the parent ...Karsten and I intend to write a tech report covering the use of TorPerf and other metrics to measure tor network performance, and to determine if certain performance tweaks results in improved or degraded performance. This is the parent ticket for this effort.
[[TicketQuery(parent=#2769,format=table,col=owner|priority|summary|points|actualpoints,order=priority)]]Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/2918Audit pidgin for leaks and other privacy issues2018-10-21T23:20:07ZJacob AppelbaumAudit pidgin for leaks and other privacy issuesPidgin is full of privacy and anonymity issues such as the ones discovered in #1676.
I propose that this is a parent ticket for an audit of pidgin for privacy related issues.
When this bug is closed and all sub bugs are closed, we can ...Pidgin is full of privacy and anonymity issues such as the ones discovered in #1676.
I propose that this is a parent ticket for an audit of pidgin for privacy related issues.
When this bug is closed and all sub bugs are closed, we can ship the TIMBB again. Or, alternatively, we can ship it with just the plugins that have been audited.
[[TicketQuery(parent=#2918,format=table,col=component|owner|summary|priority,order=priority)]]Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/3261Analyze how wrong our bridge usage statistics are2020-06-13T17:46:54ZKarsten LoesingAnalyze how wrong our bridge usage statistics areOur bridge usage statistics are based on the reports from bridges with at least 24 hours uptime. If bridges are shut down before that time, they won't tell us anything in order to protect their users' privacy.
We should find out what f...Our bridge usage statistics are based on the reports from bridges with at least 24 hours uptime. If bridges are shut down before that time, they won't tell us anything in order to protect their users' privacy.
We should find out what fraction of bridges have less than 24 hours continuous uptime to say how wrong our bridge usage statistics are.
See also Section 7 of our [technical report](https://metrics.torproject.org/papers/countingusers-2010-11-30.pdf) for a more detailed description of the bridge usage statistics and their problems.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/3362media.torproject.org needs to be more than a directory listing2018-07-03T22:32:19ZAndrew Lewmanmedia.torproject.org needs to be more than a directory listingWe've been relying upon youtube for playing tor videos. However, since tbb doesn't support flash, this makes it a catch-22 for people. media.torproject.org could use ogg video and html5 video tags to make it easy to stream the videos f...We've been relying upon youtube for playing tor videos. However, since tbb doesn't support flash, this makes it a catch-22 for people. media.torproject.org could use ogg video and html5 video tags to make it easy to stream the videos for people. tinyogg.com already exists, but does far more than media.tpo needs to do. maybe we take some portion of the tinyogg codebase and morph it into a player structure for our videos.https://gitlab.torproject.org/legacy/trac/-/issues/3466Tor build variant to support lightweight socks bridge2020-06-13T14:11:30ZRoger DingledineTor build variant to support lightweight socks bridgeMany people lately have been trying to run bridges on tiny devices.
#2764 and #3292 are about the security tradeoffs there, but while we're waiting for insight, I think we should get closer to being able to build these things.
One of D...Many people lately have been trying to run bridges on tiny devices.
#2764 and #3292 are about the security tradeoffs there, but while we're waiting for insight, I think we should get closer to being able to build these things.
One of Dan's Stanford students basically set up a python socks proxy that pulled down the Tor consensus and forwarded your traffic into one of the Tor relays. Great. Except he doesn't parse the consensus very much, doesn't check its signatures, etc.
Rather than writing a separate tool that does that, we should make a way to build a Tor binary such that you get to reuse the consensus parsing and signature checking, so it will pull down the consensus for you and check it, but the rest of Tor is left out.
(Unless we can think of an even better way to do it, that is.)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3561IOCP and bufferevents debugged and working2020-06-13T16:45:30ZNick MathewsonIOCP and bufferevents debugged and workingThis is a master ticket for solving other bufferevent and IOCP issues in Tor 0.2.3.This is a master ticket for solving other bufferevent and IOCP issues in Tor 0.2.3.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3591We must implement the whole pluggable transports thing2020-06-13T18:33:55ZGeorge 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=#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=#3591,format=table,col=component|owner|summary|priority,order=priority)]]https://gitlab.torproject.org/legacy/trac/-/issues/3592lack of web forums2020-06-13T17:19:19Zcypherpunkslack of web forumsThe tor project lacks web forums. this is an easy way to interact with users. talking to someone on the phone was great, but not wasting time and being able to read a forum would be helpful.
here are some websites that offer hosted f...The tor project lacks web forums. this is an easy way to interact with users. talking to someone on the phone was great, but not wasting time and being able to read a forum would be helpful.
here are some websites that offer hosted forums:
1. http://getsatisfaction.com/
1. http://www.zendesk.com/
1. https://www.zoho.com/support/
1. http://www.freeforums.org/
1. http://www.zetaboards.com/
Or there are many free packages available to host your own forums. if hosting your own, please provide a hidden service as well.Andrew LewmanAndrew Lewman