tor-dev January 2019

tor-dev@lists.torproject.org

21 participants
22 discussions

the consequences of deprecating debian alpha repos with every new major branch
by nusenu 21 Dec '21

21 Dec '21

Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 7

DNS-over-HTTPS (DOH) in Firefox/Torbrowser
by nusenu 01 Jul '20

01 Jul '20

Hi, since Mozilla did tests [0] on DOH [1] in Firefox I was wondering if Torbrowser developers have put any thought into that as well? Note: I'm _not_ suggesting to use DOH in torbrowser I'm just asking because the answer probably matters for exit documentation in the relay guide if clients do DNS themselves over TCP connections instead of relying on the exit (even if torbrowser is not the only tor client). thanks, nusenu [0] https://www.ghacks.net/2018/03/20/firefox-dns-over-https-and-a-worrying-shi… [1] https://datatracker.ietf.org/doc/draft-hoffman-dns-over-https/ -- https://mastodon.social/@nusenu twitter: @nusenu_

4 4

Lets give every circuit its own exit IP?
by nusenu 18 Mar '20

18 Mar '20

The unbearable situation with Google's reCAPTCHA motivated this email (but it is not limited to this specific case). This idea came up when seeing a similar functionality in unbound (which has it for a different reason). Assumption: There are systems that block some tor exit IP addresses (most likely the bigger once), but they are not blocked due to the fact that they are tor exits. It just occurred that the IP got flagged because of "automated / malicious" requests and IP reputation systems. What if every circuit had its "own" IP address at the exit relay to avoid causing collateral damage to all users of the exit if one was bad? (until the exit runs out of IPs and starts to recycle previously used IPs again) The goal is to avoid accumulating a bad "reputation" for the single used exit IP address that affects all tor users of that exit. Instead of doing it on the circuit level you could do it based on time. Change the exit IP every 5 minutes (but do _not_ change the exit IPs for _existing_ circuits even if they live longer than 5 minutes). Yes, no one has that many IPv4 addresses but with the increasing availability of IPv6 at exits and destinations, this could be feasible to a certain extend, depending on how many IPv6 addresses the exit operator has. There are exit operators that have entire /48 IPv6 blocks. problems: - will not solve anything since reputation will shift to netblocks as well (How big of a netblock are you willing to block?) - you can tell two tor users easily apart from each other even if they use the same exit (or more generally: you can tell circuits apart). There might be all kinds of bad implications that I'm not thinking off right now. - check.tpo would no longer be feasible - how can do we still provide the list of exit IPs for easy blocking? Exits could signal their used netblock via their descriptor. What if they don't? (that in turn opens new kinds of attacks where an exit claims to be /0 and the target effectively blocks everything) - more state to track and store at the exit -... some random thoughts, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

4 6

#3600 tech doc
by Richard Pospesel 13 Mar '19

13 Mar '19

Hey y'all, For the past little while I've been working on a technical overview doc for #3600 (Prevent redirects from transmitting+storing cookies+identifiers) detailing the problems, scenarios and possible solutions. Please take a look and feel free to comment, edit or add! Link: https://storm.torproject.org/grain/X4nhdNqR9fGRc7sgTefFkg/ best, -Richard

3 7

New Proposal: Preferring IPv4 or IPv6 based on IP Version Failure Count
by Neel Chauhan 29 Jan '19

29 Jan '19

Hi tor-dev@ mailing list, I have been working on Bug #27491 (https://trac.torproject.org/projects/tor/ticket/27491) and have been asked to write a proposal. My proposal is attached to this email as a text file. I would really appreciate your comments on this proposal (is it good, bad, any problems with it?). Thank You, Neel Chahan

4 6

Building meek-server with Go 1.11.5
by Matthew Finkel 27 Jan '19

27 Jan '19

Attached is a script for building meek-server. I used this for completing #29171. The newest version of Go is only available in Sid and Buster[0], so this script creates a Buster environment and installs the dependencies. The script assumes debootstrap and sudo are installed (and you have necessary privilege). As of today, a Debian Buster system should create a reproducible binary with a SHA-256 digest 6e242798f861308083e54bc0ca3989a03b0818475e9b6df4589ced10c7e3aadc (confirmed over multi-path builds). This is simply an FYI, in case anyone else want so to use it. - Matt [0] https://security-tracker.debian.org/tracker/source-package/golang-1.11

1 0

using obfs4 to tunnel to a SOCKS proxy server
by Hans-Christoph Steiner 24 Jan '19

24 Jan '19

Hey all, Hopefully this is a valid place to ask about PTs technical details. So n8fr8, uniqx (Michael Pöhn), and I are working to make an easily reproducible obfs4 client and server setup with ansible scripts uniqx got the setup working with obfs4 connecting to a port on the server side, like a webserver. Weŕe trying to figure out a way to make this obfs4 setup to behave like an SSH port forward, but weŕe banging our heads against the concept. For example, could the obfs4 server side provide a generic SOCKS proxy? Hereś the use case: wikimedia foundation wants to run their own PTs built into their own client but it needs to support multiple domains, e.g. en.wikipedia.org and commons.wikimedia.org. So we would like to have a generic SOCKS proxy for the client. Then server side, the SOCKS proxy only allows connections to a whitelist of wikimedia servers. Here are uniqxś PT projects: https://gitlab.com/uniqx/pt-obfs4proxy-minimal-demo https://gitlab.com/uniqx/pt-socks5-over-obfs4proxy https://gitlab.com/uniqx/pt-obfs4proxy-tcp-bridge https://gitlab.com/uniqx/pt-tor-obfs4-bridge-test-vm .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

3 4

anti-censorship weekly meeting notes
by Gaba 24 Jan '19

24 Jan '19

Hi! We had the weekly meeting today! Our next meeting will be in two weeks on February 7th 20:00 UTC You can find the logs here: http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-01-24-20.04.html And the contents of the pad: ANTI-CENSORSHIP work meeting pad -------------------------------- Next meeting: Thursday February 7th 20:00 UTC Weekly meetings every Thursday 20:00 UTC on #tor-meeting at OFTC (channel is logged while meetings are in progress). == Goal of this meeting == Weekly checkin about the status of anti-censorship work at Tor. Coordinate collaboration between people/teams on anti-censorship. == Links to Useful documents == Anti-censorship Roadmap: https://storm.torproject.org/shared/KXkqlNP8ouNks_ey5khZKUSbNj9ZoidXmEp80OD… Snowflake Roadmap: https://storm.torproject.org/shared/OdNtwrtRrqklh76l4PfcngBbQFDbjv_jRroj0We… Gettor Roadmap: https://storm.torproject.org/shared/rhsSl_3Pb253HPqoCdFiAdmXQ57NUG_BLvBCxqF… Bridgedb Roadmap: https://storm.torproject.org/shared/O4XpgyW_q6CAtPPO_nd_Qc16Up-jXqdJLG8gXZY… Roger's thoughts on anti-censorship's priorities: https://storm.torproject.org/shared/kU83M2pQehsnQZPzR_mwmYslAijqKgYNOEak57T… Komlo's thoughts on anti-censorship's plan: https://pad.riseup.net/p/CensorshipTeam-Planning-keep Dfcr's thoughts on anti-censorship's priorities (Snowflake only): https://share.riseup.net/#sU0_Jv7OXz8dDK5DHqDVAw ------------------------------- ---- 24th January 2019 ---- ------------------------------- == Announcements == Snowflake extensions: needs developer, let's check who/how in the browser team can do it (antonela, pili, gabA) <-- still working on this Gettor: meet outside weekly anti-censorship meeting to define scope (antonela, gaba, hiro) <-- still working on this == Discussion == Snowflake == Actions == == Updates == FORMAT! Name: Last week: - What you worked on last week a This week: - What you are planning to work on next week (related to anti-censorship work). Help with: - Something you may need help with. Gaba: This week (01/24): preparation for roadmap exercise with network team ahf: Last week: - Documenting current Snowflake architecture and identify problems related to scalability and usability (both for developers and users). (#28848) - Documenting basic WebRTC usage to allow other developers to quickly join in on it. (#28048) [<-- wrong ticket number? 28048 is "Metrics: Allow to search for relays per continent"] - Identifying bug where Snowflake proxy becomes unresponsive in a smaller environment. (possibly #25429?) This week (01/24): - Was out sick friday/monday, didn't do much. - Preparing for network team meeting in brussels where I hope to help the new hire for the anti-censorship team with things related to this: - A talk about Snowflake that will hopefully make everyone be able to look at the code quickly. - Email to Kat about some scalability concerns that I think is worth having in mind about Snowflake: Numbers of bridges, etc. kat5: Working on: - report 2 - private bridge guide for NGOs (hold off until we figure out a strategy for making set-up easy) anto: Working on: - Snowflake Web Extension UI - https://trac.torproject.org/projects/tor/ticket/23888 - Put together a PRD for Gettor, needs more info and review - https://docs.google.com/document/d/18R_tUnqfFkn7d93w0pEbBOLxB62KAWHbUGd5MPK… Help with - snowflake extension: in need of a developer pili (offline): working on: - gettor - agreed on next steps to deploy refactored code with ilv and hiro - still need to define project scope with gaba, antonela and hiro help with: - Browser team can't commit anyone to work on snowflake web extension - can we not just: a) wait for integration into cupcake (see https://github.com/glamrock/cupcake/issues/24) - we can help them with this also b) wait for anti-censorship developer - we need to also think about who is going to maintain this webextension dcf: Last week: - minor UX improvement for Snowflake proxy (#25722) - antonela has more ambitious changes in #27385 - monkeying with uTLS in meek-client (#29077) - meek and snowflake sysadmin This week: - more uTLS in meek-client, restore proxy support - more sysadmin (#29171, #29172) Samdney: Working on: - Will also have a look at the WebExtension ticket #23888 :) - Looking for something where they can help!!! - If you have anything in the direction of "research" or "investigation" in something, then I'm your guy! :) (- I'm working on a research project about censor <-> classical attacker in game theory. That's maybe later, when I have results :), interesting for UX/dev stuff.) _hc/eighthave: uniqx and I have been working on ways to integrate PTs into apps easily. we have a working client/server automation setup based in Python. We also were trying to do a more generic proxy, https://lists.torproject.org/pipermail/tor-dev/2019-January/013637.html n8fr8 is working on getting obfs4 into our Android Pluggable Transports library. he's having trouble getting it to connect to our server automation In Feb, I'll be working on figuring out a good URL scheme for bridge configuraton - #15035 OTF accepted our Concept Note with Stephen Farrell for working on ESNI and ensuring circumvention is included. We are submitting the proposal now, chances look good!

1 0

RFC: Using `utls` in meek_lite.
by Yawning Angel 24 Jan '19

24 Jan '19

Hello, I just pushed a change to obfs4proxy master to use `utls` to mask the ClientHello signature (currently Chrome 70.x). https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b… I understand that this is being worked on for the original meek (see: https://bugs.torproject.org/29077), but I felt inspired and it was relatively easy to get something working. Caveats: * This is only lightly tested, and may be doing something wrong or distinct. It seems to work well enough to watch videos over it. YMMV. * Azure uses HTTP 2. Not really a problem. * `utls.HelloFirefox_Auto` will fail to handshake with Azure due to an incompatible group being negotiated. * `utls.HelloChrome_Auto` ironically fails to handshake with `google.com` in a standalone test case for me. * `utls.HelloIOS_Auto` seems to work in all cases, so I may switch to that before I tag. Questions, comments, feedback appreciated, -- Yawning Angel

2 7

Modifying Path Selection based on geography
by sarpedon montecarlo 22 Jan '19

22 Jan '19

Hello there. I recently started to do some modifications on tor path selection by using stem, torflow/op-addon and txtorconn. but as long as i enable __LeaveStreamsUnattached option, tor will not function properly. so i decided to hack the source for this feature i seek: custom country for each position: entry:{{entry country-code}} middle:{{middle country-code}} exit:{{country-code}} i really appreciate you guys give me some hint, that which part of the source i must start to hack? i have dived into circuitbuild.c and some other core/or modules but i am confused where to start. thanks in advance.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev January 2019