Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:00:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33085decomission unifolium/kvm2, 6 VMs to migrate2020-06-13T17:00:42Zanarcatdecomission unifolium/kvm2, 6 VMs to migrate * [x] cupani.torproject.org (git-rw) migrated in #33446
* [x] polyanthum.torproject.org (bridges) #33448
* [x] omeiense.torproject.org (onionoo.torproject.org) (possibly to decom? see #32268) #33447
* [x] savii.torproject.org (static... * [x] cupani.torproject.org (git-rw) migrated in #33446
* [x] polyanthum.torproject.org (bridges) #33448
* [x] omeiense.torproject.org (onionoo.torproject.org) (possibly to decom? see #32268) #33447
* [x] savii.torproject.org (static content backend) retired in #33441
* [x] build-x86-07.torproject.org (buildbox) retired in #33442)
* [x] bracteata.torproject.org (sandstorm) retired in #32390
Requires a new gnt node (#33081).anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/33078Explicit Congestion Control Meta-Proposal2020-06-13T15:50:27ZMike PerryExplicit Congestion Control Meta-ProposalWe should review all of the past congestion control attempts in tor, and go through new options that haven't been tried yet.We should review all of the past congestion control attempts in tor, and go through new options that haven't been tried yet.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/32900Reimplement and generalise BridgeDB?2020-06-13T18:29:56ZPhilipp Winterphw@torproject.orgReimplement and generalise BridgeDB?Over at #30946, I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking about a re...Over at #30946, I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking about a rewrite of BridgeDB. Here's how I see the (dis)advantages breaking down:
Disadvantages:
* Re-implementations are never as smooth and straightforward as anticipated. It will take a lot of time.
* We won't (easily) be able to use Stem to parse bridge descriptors. We could extend [zoossh](https://gitweb.torproject.org/user/phw/zoossh.git/) though.
Advantages:
* We could re-implement the service in golang because the anti-censorship team is comfortable in the language.
* We could generalise the concept of BridgeDB: What goes in should be an abstract type of proxy (be it bridge descriptors, snowflake-style proxy registrations, or maybe even Lantern proxies) and distributors (as we already have them in BridgeDB) determine who gets these proxies.
* We would design the service with redundancy and "containerisation" in mind.
* It would make it easier to add new features, especially significant ones, like a new distributor.
* A re-implementation may be a return on investment and save us time in the long run.
Note that we don't need to abandon BridgeDB and then redirect our focus to its re-implementation. I would instead like to spend some hours experimenting with a new design in parallel to maintaining BridgeDB. We also don't need to aim for a feature-complete replacement of BridgeDB. For example, we don't need to PGP-sign emails. If all of the above proves fruitful, we can gradually transition to the new design.
Thoughts? Any other features or architectural changes we should make in a re-implementation?https://gitlab.torproject.org/legacy/trac/-/issues/31873Create new bridge distribution mechanisms2020-06-13T18:29:46ZPhilipp Winterphw@torproject.orgCreate new bridge distribution mechanismsBridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is prob...BridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is problematic because bridges.torproject.org is blocked in most places that matter and our CAPTCHA is good at keeping out users (#29695) but not so good at keeping out bots (#31252). Moat remains relatively useful because it uses domain fronting but it still relies on a CAPTCHA to fight off bots.
It's time to think about new and/or significantly improved bridge distribution methods. How can we get bridges into the hands of users while making it difficult for adversaries to get them all? How can we make BridgeDB's CAPTCHA more resistant against bots and easier for users?https://gitlab.torproject.org/legacy/trac/-/issues/31182Add more typesafe containers to tor2020-06-13T15:43:40ZNick MathewsonAdd more typesafe containers to torAs we migrate slowly towards Rust, we'll want a solution that lets us move to type-safe containers like vec and hashmap.As we migrate slowly towards Rust, we'll want a solution that lets us move to type-safe containers like vec and hashmap.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31122Use subsystems architecture in more places2020-06-13T15:43:32ZNick MathewsonUse subsystems architecture in more placesWe introduced a "subsystems" architecture in Tor 0.3.5, where each module registers functions for setting itself up and tearing itself down. We now use this mechanism in `lib` and `core/mainloop`. We should push its usage through the r...We introduced a "subsystems" architecture in Tor 0.3.5, where each module registers functions for setting itself up and tearing itself down. We now use this mechanism in `lib` and `core/mainloop`. We should push its usage through the rest of `core`, and into more of `features` and `app`.
We shouldn't try to do this all in one go. Please open subtickets for individual modules.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31121Use publish-subscribe system in more places2020-06-13T15:43:31ZNick MathewsonUse publish-subscribe system in more placesSome likely code that we could replace includes:
* directory_info_has_arrived
* note_that_we_have_completed_a_circuit
* note_that_we_maybe_cant_complete_circuits
* circuit_has_opened()
* All "we got a new consensus" events:
...Some likely code that we could replace includes:
* directory_info_has_arrived
* note_that_we_have_completed_a_circuit
* note_that_we_maybe_cant_complete_circuits
* circuit_has_opened()
* All "we got a new consensus" events:
* notify_before_networkstatus_changes
* notify_after_networkstatus_changes
* clock jump events:
* circuit_note_clock_jumped
* netstatus_note_clock_jumped
There are probably more!
As we do these, we should open subtickets, and not try to do them all as a part of this ticket.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30716Improve the obfs4 obfuscation protocol2021-07-09T14:26:59ZPhilipp Winterphw@torproject.orgImprove the obfs4 obfuscation protocolAs part of our work for Sponsor 28, we will evaluate and improve the obfs4 obfuscation protocol, which may result in obfs5.
Roger started the discussion [on our anti-censorship-team mailing list](https://lists.torproject.org/pipermail/a...As part of our work for Sponsor 28, we will evaluate and improve the obfs4 obfuscation protocol, which may result in obfs5.
Roger started the discussion [on our anti-censorship-team mailing list](https://lists.torproject.org/pipermail/anti-censorship-team/2019-May/000015.html). Relevant reading is the CCS'15 paper [Seeing through Network-Protocol Obfuscation](https://censorbib.nymity.ch/#Wang2015a) and the S&P'16 paper [SoK: Towards Grounding CensorshipCircumvention in Empiricism](https://censorbib.nymity.ch/#Tschantz2016a).
Let's use this ticket to keep track of this effort. Below is a list of ideas that we may or may not want to incorporate in obfs5.
== Randomisation
Obfs4 already implements randomisation for packet lengths and inter-arrival times but there are other protocol aspects that we can randomise. Note that the adoption of these strategies may complicate censorship analysis: if obfs5 instance X looks very different from obfs5 instance Y, then X may end up getting blocked while Y still works. Instead of saying "obfs5 is blocked," one may then have to be more specific and say "the obfs5 instances that rely on UDP are blocked."
* **Payload**: All bytes that obfs4 writes to the wire are randomly distributed. These high-entropy packets may or may not be common on the Internet. We could evade a "high-entropy filter" by having obfs4 servers derive a formal language from the shared secret. This language could, say, use dummy clear-text headers. The [LibFTE](http://libfte.org/) library may be helpful here.
* **Cover traffic**: [dcf](https://lists.torproject.org/pipermail/tor-dev/2017-June/012310.html) explains that obfs4 only sends data when it's given data to send. To improve on this, as dcf suggests, we could make obfs5 send data even when the application has nothing to send.
* **Packet directions**: An obfs4 flow begins with the client sending data to the server. We could randomise packet directions and have, say, the server talk first with a server-specific probability.
* **Transport protocol**: An obfs4 server could talk either TCP or UDP or SCTP. This may very well not be worth the effort.
== Lessons learned from [CCS'15 paper](https://censorbib.nymity.ch/#Wang2015a)
* DPI boxes tend to classify flows by only inspecting the first N packets of a flow. Keeping state is expensive, after all. We could exploit this by relaxing our obfuscation techniques after N packets to increase throughput.
* The paper's data set may not be representative of what countries or ISPs would see:
* It's "only" a university uplink. Universities typically have policies that prohibit file sharing such as BitTorrent. BitTorrent's "message stream encryption" may look similar to obfs3 and obfs4.
* The data sets are from 2014, 2012, and 2010, respectively. That's a long time in Internet years.
* The detectors' false positive rates are non-trivial and, as the authors point out themselves, would be problematic for a censor given that non-obfuscated traffic significantly outweighs obfuscated traffic.
* Does the data set only contain one obfs4 server instance? This may have affected their results.
== Miscellaneous
* [yawning writes](https://trac.torproject.org/projects/tor/ticket/30716#comment:1) that obfs4 doesn't easily support backward incompatible protocol alterations.
* [yawning writes](https://trac.torproject.org/projects/tor/ticket/30716#comment:3) that the framing could use better cryptography.
* Crazy idea: Use a modified TCP stack that ignores RST and FIN segments, so the GFW's on-path devices cannot tear down the connection. Instead, the obfs5 protocol could signal the end of the connection in an authenticated control frame. We could ignore RST and FIN segments by using firewall rules, or to get more crazy, by shipping a user space TCP stack (this may be easy to fingerprint, though).Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28005Officially support onions in HTTPS-Everywhere2022-09-01T22:43:24ZGeorge KadianakisOfficially support onions in HTTPS-EverywhereThe plan:
A major UX issue for onion services is their huge addresses. We want to fix this issue because an address with 56 random characters confuses people, it makes it harder to pass the address around, and it also makes it much hard...The plan:
A major UX issue for onion services is their huge addresses. We want to fix this issue because an address with 56 random characters confuses people, it makes it harder to pass the address around, and it also makes it much harder to verify it.
There is a field of literature called "secure name systems" but none of the candidates are good enough for us right now. Hence, we present a hotfix that might offer a situational relief for users for the medium-term future, until we come up with something better, or while we experiment with more solutions. I suggest we keep this ticket focused to this idea, instead of debating why this and not that since we've already been doing this for far too long.
The plan is to use the HTTPS-Everywhere extension that we already have in Tor Browser, and encourage people to write their own rulesets for onions. We are talking about community-maintained rulesets and nothing that is officially maintained by The Tor Project or by HTTPS-Everywhere. This ticket is about making it easier for people to create, import and use this rulesets. We are talking about UI/UX improvements, writing blog posts and doing Q&A.
Here are some example of community rulesets we can imagine:
* The SecureDrop ruleset: where securedrop makes a ruleset with their whole directory. People can download that to quickly visit securedrop destinations, by going to securedrop-nyt.tor.onion .
* The Torproject ruleset: where torproject makes a ruleset with all their onions. We developers can use that to quickly visit Tor sites over onion, by going to tor-trac.tor.onion instead of remembering the onion.
* The Bitcoin ruleset: where a "trusted" bitcoin entity publishes a ruleset with various cryptocurrency-related rules that allow people to quickly visit them.
This approach has both positives and negatives (I assure you this is the case with every "secure naming" project out there):
* Positives: Good security if the ruleset is taken from a trusted source. No state keeping. Reachable engineering effort. No global names, hence no fear of name squatting. Easy to understand tradeoffs.
* Negatives: Terrible security if the ruleset is evil. No global names: If you want people to use your shorten onion name, you need to persuade them to use your ruleset.
Here are some HTTPS-Everywhere issues we need to solve based on my Mexico notes:
* Be able to stop update channels per-channel.
* Need good UI to easily look and understand rules.
* Need to implement file extension to install ruleset with one-click from web button.
Here are some issues we need to think about:
* We need good user text to make sure that people don't shoot themselves in the foot too often by installing bad rulesets and whatnot (they already do it daily when they open onions from "search enginers" or reddit).
* Which tld to use? If we use .tor we open ourselves to DNS leaks in normal browsers. If we use .tor.onion that might be confusing to people.
* Are there any issues with SSL?
More resources:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/OnionV3ux
https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/HTTPSEverywhereNotes
https://blog.torproject.org/cooking-onions-names-your-onionshttps://gitlab.torproject.org/legacy/trac/-/issues/25753Check/enforce path restrictions for each path position2022-06-24T14:25:40ZMike PerryCheck/enforce path restrictions for each path positionFor the vanguard torrc options, we may want to check that each layer has at least one node from a different /16 and different node family than others in that layer, to ensure that a path can always be built using the vanguard set.
We ma...For the vanguard torrc options, we may want to check that each layer has at least one node from a different /16 and different node family than others in that layer, to ensure that a path can always be built using the vanguard set.
We may also want to do the same thing for Tor's Primary Guard set from Prop271, to ensure that an adversary can't force the user to pick guards randomly from Sampled Guards.
Doing both of these things at once should allow us to drop #24487.
See also: https://gitweb.torproject.org/torspec.git/tree/proposals/291-two-guard-nodes.txt#n33Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14424Enhance policies (exit, reachableaddresses, etc) to support hostnames2020-06-13T14:42:10ZTracEnhance policies (exit, reachableaddresses, etc) to support hostnamesHello. First of all, amazing software! Thank you for this. I was wondering if there is a way to edit torrc to only connect to comcast, att, mit.edu etc..As you can edit the file to only connect to US servers, but I need it for specific I...Hello. First of all, amazing software! Thank you for this. I was wondering if there is a way to edit torrc to only connect to comcast, att, mit.edu etc..As you can edit the file to only connect to US servers, but I need it for specific ISP's. Thank you!
**Trac**:
**Username**: KyuskeTor: very long termhttps://gitlab.torproject.org/legacy/trac/-/issues/7028Implement Adaptive Padding or some variant and measure overhead vs accuracy2022-03-22T13:02:42ZMike PerryImplement Adaptive Padding or some variant and measure overhead vs accuracyAs a defense against Website Traffic Fingerprinting, we should implement a tunable cover traffic defense that we could set from the consensus with a value dependent upon available Guard bandwidth relative to Exit capacity.
My favorite f...As a defense against Website Traffic Fingerprinting, we should implement a tunable cover traffic defense that we could set from the consensus with a value dependent upon available Guard bandwidth relative to Exit capacity.
My favorite from the research literature is http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf, because it appears to be tunable in this fashion.
The "BUFLO" variant proposed by this paper is better specified, but it's not clear it actually performs better for a given overhead quantity: http://www.cs.sunysb.edu/~xcai/fp.pdf
This is likely a research task. People who attempt it should also read http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf (Slides: http://www.cse.psu.edu/~tjaeger/cse543-f06/presents/Kiran_baserate.pdf)Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5742Prototype image cache url isolation2020-06-13T05:46:48ZMike PerryPrototype image cache url isolationThere is a suspicious comment in imgLoader::LoadImage() about ignoring CacheKey, which we use for domain isolation of the cache. We need to test sourcing the same image url from two different url bar domains to make sure the cache is not...There is a suspicious comment in imgLoader::LoadImage() about ignoring CacheKey, which we use for domain isolation of the cache. We need to test sourcing the same image url from two different url bar domains to make sure the cache is not shared between them.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/5477Surprising DOM origins before HTTPS-E/NoScript redirects have completed2020-06-13T16:27:03ZTracSurprising DOM origins before HTTPS-E/NoScript redirects have completedhttp://majorsecurity.net/html5/ios51-demo.html
!^ Here is the demo of address spoofing.
With HTTPS-Everywhere enabled in latest Nightly - clicking the button opens a new tab with "apple.com" address. But this is a spoofed address, pres...http://majorsecurity.net/html5/ios51-demo.html
!^ Here is the demo of address spoofing.
With HTTPS-Everywhere enabled in latest Nightly - clicking the button opens a new tab with "apple.com" address. But this is a spoofed address, press CTRL+U to watch the source code of that page.
**Trac**:
**Username**: Drugoyma1ma1https://gitlab.torproject.org/legacy/trac/-/issues/5379Design adaptive n23 algorithm that works2020-06-13T14:18:10ZRoger DingledineDesign adaptive n23 algorithm that worksIn #4488 we put together a patch based on Mashael and Kevin's work on N23. It includes the static N23 algorithm and also an adaptive algorithm that lowers N3 when cells spend too long in connection outbufs.
Except Kevin's original adapt...In #4488 we put together a patch based on Mashael and Kevin's work on N23. It includes the static N23 algorithm and also an adaptive algorithm that lowers N3 when cells spend too long in connection outbufs.
Except Kevin's original adaptive algorithm a) tracks cell time in a really sketchy way, and b) was shown in the defenestrator paper to be worse than the static one.
We can solve "a" at least by using our cell statistics: see cell_waiting_time in connection_or_flush_from_first_active_circuit().
Once somebody writes a patch to do what the adaptive n23 algorithm aimed to do, but with our cell statistics, this will turn into a research problem to see if there are particular tuning values that work well.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2513Mike Perry's Iteration Report 20110131-201102062011-02-10T01:36:58ZMike PerryMike Perry's Iteration Report 20110131-20110206# Ticket Log
Closed:
#2421: Estimated: 1/1, Actual: 1/1
#2428: Estimated: 10/10, Actual: 3/3
#2490: Estimated: 2/2, Actual: 2/2
Need Closing:
#1110: Estimated: 2/2, Actual: 2/2
#2485: Estimated: 2/2, Actual: 2/2
Partials:
#2471: ...# Ticket Log
Closed:
#2421: Estimated: 1/1, Actual: 1/1
#2428: Estimated: 10/10, Actual: 3/3
#2490: Estimated: 2/2, Actual: 2/2
Need Closing:
#1110: Estimated: 2/2, Actual: 2/2
#2485: Estimated: 2/2, Actual: 2/2
Partials:
#2471: Estimated: 1/6, Actual: 1/?
#2468: Estimated: 3/7, Actual: 5/?
# Stats
Start Ticket: #2469
Points Opened: 15
Actual Points Opened: 15
End Ticket: #2511
Points Done: 21
Actual Points Done: 16Mike PerryMike Perryhttps://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: unspecified