Re: [tor-dev] RFC: Using `utls` in meek_lite.
On Thu, Jan 24, 2019 at 07:44:48AM +, Yawning Angel wrote: > On 1/24/19 7:38 AM, David Fifield wrote: > > I see, you're right. It has to do with the reuse of the initConn. > > A proper "general" solution that solves that problem and the ALPN issue > is to have a `initConn` and `http.RoundTripper` instance per destination > host, and some additional locking. > > With more implementation cleverness this could be brought down to two > `http.RoundTripper` instances, and a host -> pointer + net.Conn map, and > some locking. > > But for something like meek_lite where the number of destination hosts > is not large, the existing wrapper works fine and I don't see much > reason to over engineer it. I don't disagree, it's fine for this use case. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Using `utls` in meek_lite.
On 1/24/19 7:38 AM, David Fifield wrote: > I see, you're right. It has to do with the reuse of the initConn. A proper "general" solution that solves that problem and the ALPN issue is to have a `initConn` and `http.RoundTripper` instance per destination host, and some additional locking. With more implementation cleverness this could be brought down to two `http.RoundTripper` instances, and a host -> pointer + net.Conn map, and some locking. But for something like meek_lite where the number of destination hosts is not large, the existing wrapper works fine and I don't see much reason to over engineer it. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Using `utls` in meek_lite.
On Thu, Jan 24, 2019 at 07:33:39AM +, Yawning Angel wrote: > On 1/24/19 6:47 AM, David Fifield wrote: > > // This also assumes that req.URL.Host will remain constant for the > > // lifetime of the roundTripper, which is a valid assumption for > > meeklite. > > > > Am I wrong, or is the actual restriction less strict? You can reuse the > > roundTripper for different hosts--the ServerName is taken from the addr > > argument to dialTLS--but only if those different hosts negotiate the > > same ALPN, because the choice of http.Transport or http2.Transport is > > made only once and persists for the lifetime of the roundTripper. > > The lock protecting `roundTripper.initConn` is only held in `dialTLS`, > and the `roundTripper.transport` is not protected by a lock at all. > > If the target host changes and there is simultaneous access (two threads > call into `roundTripper.RoundTrip` right after initialization > simultaneously), there is no guarantee that the connection used to > create the inner `http.RoundTripper` instance will be passed to the > correct thread. I see, you're right. It has to do with the reuse of the initConn. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Using `utls` in meek_lite.
On 1/24/19 6:47 AM, David Fifield wrote: > // This also assumes that req.URL.Host will remain constant for the > // lifetime of the roundTripper, which is a valid assumption for > meeklite. > > Am I wrong, or is the actual restriction less strict? You can reuse the > roundTripper for different hosts--the ServerName is taken from the addr > argument to dialTLS--but only if those different hosts negotiate the > same ALPN, because the choice of http.Transport or http2.Transport is > made only once and persists for the lifetime of the roundTripper. The lock protecting `roundTripper.initConn` is only held in `dialTLS`, and the `roundTripper.transport` is not protected by a lock at all. If the target host changes and there is simultaneous access (two threads call into `roundTripper.RoundTrip` right after initialization simultaneously), there is no guarantee that the connection used to create the inner `http.RoundTripper` instance will be passed to the correct thread. Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Using `utls` in meek_lite.
On Mon, Jan 21, 2019 at 05:12:41AM +, Yawning Angel wrote: > 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/4d453dab2120082b00bf6e63ab4aaeeda6b8d8a3 // This also assumes that req.URL.Host will remain constant for the // lifetime of the roundTripper, which is a valid assumption for meeklite. Am I wrong, or is the actual restriction less strict? You can reuse the roundTripper for different hosts--the ServerName is taken from the addr argument to dialTLS--but only if those different hosts negotiate the same ALPN, because the choice of http.Transport or http2.Transport is made only once and persists for the lifetime of the roundTripper. For the same reason, I don't think we'll be able to use HelloRandomized, only HelloRandomizedALPN or HelloRandomizedNoALPN. Otherwise we may negotiate different ALPN even against the same server during the lifetime of roundTripper. I tried adding a conn.SetReadDeadline(time.Now().Add(10*time.Second)) inside dialTLS to force it to re-dial frequently, and with HelloRandomized it does indeed eventually trip the "horrifically wrong" branch with an error like: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x00\x00\x12\x04\x00\x00\x00\x00\x00\x00\x05\x00\x10\x00\x00\x00\x03\x00\x00\x00\xfa\x00\x06\x00\x10\x01@" Despite the error, the client recovers quickly, redialing until it gets a compatible ALPN. ___ 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
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. ___ 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
On 1/23/19 10:42 AM, Hans-Christoph Steiner wrote: > 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. You don't/can't, with mainline obfs4proxy. > 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). Regards, -- Yawning Angel signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] using obfs4 to tunnel to a SOCKS proxy server
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=0xE9E28DEA00AA5556 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
