Re: [tor-dev] using obfs4 to tunnel to a SOCKS proxy server
On Fri, Jan 25, 2019 at 12:03:19AM +0100, Hans-Christoph Steiner wrote: > Is this the same with other PT 1.1 daemons? Or would Snowflake be > different? Seems like with obfs4, the load balancer using SNI would > probably be the easiest for the wikipedia use case. It will be the same with any other transport. They all have a uniform interface through TOR_PT_ORPORT or TOR_PT_EXTENDED_SERVER_PORT. Moat uses something basically similar with meek-server, feeding the ORport into the local BridgeDB web server. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] using obfs4 to tunnel to a SOCKS proxy server
David Fifield: > On Wed, Jan 23, 2019 at 11:41:42AM +, Yawning Angel wrote: >>> For example, could the obfs4 server side provide a generic SOCKS proxy? >> >> There is no functionality for doing such a thing in mainline obfs4proxy. >> >> What currently will work is any one of: >> >> * Stick a proxy server of your choice behind the obfs4proxy server. >> From the application end it will essentially be connecting to a (for >> example) SOCKS5 proxy over another SOCKS5 proxy. >> >> * Connect the obfs4proxy server to a load-balancer or reverse-proxy >> that re-dispatches requests to the correct location based on the SNI >> block or `Host` header (depending on how you want to treat TLS). > > This is the right answer. Fundamentally you need two layers of proxying: > one at the PT layer (obfs4proxy PT interface) and one at your > application layer (where you implement problem-specific logic like > domain whitelists). > > On the server, you will point TOR_PT_ORPORT at a SOCKS server or load > balancer, rather than directly at the target web server. The > obfs4_server.sh script will work fine for that; you could also try > https://github.com/twisteroidambassador/ptadapter. The SOCKS server will > have to support a destination whitelist--or you could just put it on a > host with an appropriate outgoing firewall. Instead of a SOCKS server, > you could use load balancer/reverse proxy like Yawning says. Here are a > few that have SNI proxying (I've personally only used sslh): > https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/ > https://github.com/yrutschle/sslh > https://github.com/dlundquist/sniproxy > > But you're going to encounter an undesirable feature of this setup: > there's a 1:1 relationship between application-layer connections and > obfuscation-layer tunnels. That is, if the app makes 2 HTTPS connections > to 2 different Wikimedia domains, there will be 2 obfs4 tunnels > happening. It will work, but it's more conspicuous and will notionally > make website fingerprinting easier. What you may want is a multiplexing > protocol that collapses multiple streams into one on the client side (to > feed into the obfs4 tunnel) and splits them back apart again on the > server side. (In the usual Tor setup, it's the Tor protocol that serves > this multiplexing function--you only have one long-lived connection to > your guard, not a separate connection for every application-layer > stream.) Unfortunately I don't know of any out-of-the-box that does > this. You might try https://github.com/xtaci/smux; also lately I've been > thinking a lot about applying https://github.com/lucas-clemente/quic-go > to this problem. Sounds like these are the right direction. Just to clarify: I was thinking of obfs4 like an SSH port forward, not as the provider of a SOCKS proxy. So "server-side" means running daemon alongside obfs4proxy to do the other bits. What you two have outlined sounds like exactly that. Is this the same with other PT 1.1 daemons? Or would Snowflake be different? Seems like with obfs4, the load balancer using SNI would probably be the easiest for the wikipedia use case. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] anti-censorship weekly meeting notes
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_ey5khZKUSbNj9ZoidXmEp80ODDMsN Snowflake Roadmap: https://storm.torproject.org/shared/OdNtwrtRrqklh76l4PfcngBbQFDbjv_jRroj0WeSY0B Gettor Roadmap: https://storm.torproject.org/shared/rhsSl_3Pb253HPqoCdFiAdmXQ57NUG_BLvBCxqF_Kqp Bridgedb Roadmap: https://storm.torproject.org/shared/O4XpgyW_q6CAtPPO_nd_Qc16Up-jXqdJLG8gXZYX_e2 Roger's thoughts on anti-censorship's priorities: https://storm.torproject.org/shared/kU83M2pQehsnQZPzR_mwmYslAijqKgYNOEak57TSLAt 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_tUnqfFkn7d93w0pEbBOLxB62KAWHbUGd5MPKLB8w/edit?usp=sharing 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
