October 2019 - anti-censorship-team

Next steps for unclassifiable protocols
by Roger Dingledine 04 Oct '20

04 Oct '20

Hi folks, Here are some brainstorming thoughts to get us started improving our "unclassifiable protocols" idea. ---------------------------------------------------------------------- For context, right now we have essentially one deployed design in this space, which is obfs4: https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4… This protocol does a short handshake (one client message, one server message) to establish session keys, then it just sends bytes back and forth with an (additional) layer of encryption so no payload bytes assist an attacker with doing content-based protocol classification. ---------------------------------------------------------------------- One of the more thorough analyses of obfs4 comes from the FTE folks: https://www.freehaven.net/anonbib/#ccs2015obfsdetection where they show a classifier that assesses entropy of the first server-side packet, plus looking at the length of that initial message, and they can consistently pick out obfs4 flows with only a 0.25% false positive rate compared to background traffic they recorded at their university. That false positive rate is where it gets interesting: it sounds good until we realize that it means it flags 1 in every 400 flows as being obfs4, i.e. it falsely tags about 36000 flows in the 14M flow dataset. And the false positives aren't randomly distributed either: 1.22% of their SSL flows are falsely tagged as obfs4, and it's the ones where the SNI in the SSL handshake has a lot of entropy (because everything else in the SSL handshake is already random). Also, entire protocols like RTMP get caught up and tagged as obfs4, because their handshake starts out with a block of random bytes. A key takeaway is that if they ran this classifier, with its high true positive rate and low false positive rate, on a large country's network traffic, approximately none of the flows that it would tag as obfs4 would actually be obfs4. Their Section 7 in that paper has a good discussion of the base rate issues and how they apply here. Are there other papers that design or analyze classifiers for obfs4? ---------------------------------------------------------------------- The good news: It would seem that obfs4 is most effective in the "long tail of varied traffic" scenario. That is, considering the spectrum between "small corporate network" and "China backbone", obfs4 needs that more broad background traffic in order to make its false positives too painful to block. The bad news: I still worry about an attack that puts together many building blocks, each of which individually is like the "1% false positive rate" classifier in the above paper, but that together drive their false positive rate low enough that blocking is safe to do. One observation there is that the more complexity there is to a protocol, the harder it is to "really" look like it, i.e. to match it in all dimensions at once. Consider this lovingly handcrafted graph, where the X axis is how thoroughly we try to look like some expected protocol, and the Y axis is how close we can get to making the adversary unwilling to block us: 1_| |_1 | | |\ /| | \ / | | \ / | | \ / | 0_| \___________________________________________/ |_0 | | There's a huge valley in the middle, where we're trying to look like something, but we're not doing it well at all, so there is little damage from blocking us. The ramp on the right is the game that FTE tries to play, where in theory if they're not perfectly implementing their target protocol then the adversary can deploy a distinguisher and separate their traffic from the "real" protocol, but in practice there are enough broken and weird implementations of the protocol in the wild that even being "close enough" might cause the censor to hesitate. And the ramp on the left is our unclassifiable traffic game, where we avoid looking like any particular expected protocol, and instead rely on the long tail of legitimate traffic to include something that we blend with. Observation: *both* of these ramps are in the "broken in theory, but works in practice" situation. I started out thinking it was just the obfs4 one, and that the FTE one was somehow better grounded in theory. But neither side is actually trying to build the ideal perfect protocol, whatever that even is. The game in both cases is about false positives, which come from messy (i.e. hard to predict) real-world background traffic. One research question I wrestled with while making the graph: which ramp is steeper? That is, which of these approaches is more forgiving? Does one of them have a narrower margin for error than the other, where you really have to be right up against the asymptote or it doesn't work so well? For both approaches, their success depends on the variety of expected background traffic. The steepness of the right-hand (look-like-something) ramp also varies greatly based on the specific protocol it's trying to look like. At first glance we might think that the more complex the protocol, the better you're going to need to be at imitating it in all dimensions. That is, the more aspects of the protocol you need to get right, the more likely you'll slip up on one of them. But competing in the other direction is: the more complex the protocol, the more broken weird implementations there could be in practice. I raise the protocol complexity question here because I think it has something subtle and critical to do with the look-like-nothing strategy. Each dimension of the protocol represents another opportunity to deploy a classifier building block, where each classifier by itself is too risky to rely on, but the composition of these blocks produces the killer distinguisher. One of the features of the unclassifiable protocol that we need to maintain, as we explore variations of it, is the simplicity: it needs to be the case that the adversary can't string together enough building-block classifiers to reach high confidence. We need to force them into building classifiers for *every other protocol*, rather than letting them build a classifier for our protocol. (I'll also notice that I'm mushing together the notion of protocol complexity with other notions like implementation popularity and diversity: a complex proprietary protocol with only one implementation will be no fun to imitate, but the same level of complexity where every vendor implements their own version will be much more workable.) ---------------------------------------------------------------------- I've heard two main proposed ways in which we could improve obfs in theory -- and hopefully thus in practice too: (A) Aaron's idea of using the latest adversarial machine learning approaches to evolve a traffic transform that resists classifying. That is, play off the classifiers with our transform, in many different background traffic scenarios, such that we end up with a transform that resists classifying (low true positive and/or high false positive) in many of the scenarios. (B) Philipp's idea from scramblesuit of having the transform be parameterized, and for each bridge we choose and stick with a given set of parameters. That way we're not generating *flows* that each aim to blend in, but rather we're generating bridges that each aim to blend differently. This diversity should adapt well to many different background traffic scenarios because in every scenario some bridges might be identified but some bridges will stay under the radar. At first glance these two approaches look orthogonal, i.e. we can do both of them at once. For example, Aaron's approach tells us the universe of acceptable parameters, and Philipp's approach gives us diversity within that universe. Aaron: How do we choose the parameter space for our transforms to explore? How much of that can be automated, and how much needs to be handcrafted by subject-matter-experts? I see how deep learning can produce a magic black-box classifier, but I don't yet see how that approach can present us with a magic black-box transform. And as a last note, it would sure be nice to produce transforms that are robust relative to background traffic, i.e. to not be brittle or overfit to a particular scenario. Otherwise we're giving up one of our few advantages in the arms race, which is that right now we force the censor to characterize the traffic -- including expected future traffic! -- and assess whether it's safe to block us. There. Hopefully some of these ideas will cause you to have better ideas. :) --Roger

2 2

Cancelling IRC meeting on November 7
by Philipp Winter 30 Oct '19

30 Oct '19

Both Cecylia and I will be travelling and won't be able to host the anti-censorship meeting on November 7. Let's cancel this one. Cheers, Philipp

1 0

Turbo Tunnel in obfs4proxy (survives TCP connection termination)
by David Fifield 21 Oct '19

21 Oct '19

I posted this at https://github.com/net4people/bbs/issues/14#issuecomment-544747519 but it's relevant to anti-censorship in Tor. Here are proof-of-concept branches implementing the turbo tunnel idea in obfs4proxy, one using kcp-go/smux and one using quic-go: * https://dip.torproject.org/dcf/obfs4/tree/reconnecting-kcp * https://dip.torproject.org/dcf/obfs4/tree/reconnecting-quic As diffs: * [Changes needed to add kcp-go/smux to plain obfs4proxy](https://dip.torproject.org/dcf/obfs4/compare/aa7313b7eb78b7546a… * [Changes needed to adapt kcp-go/smux to quic-go](https://dip.torproject.org/dcf/obfs4/compare/b5d6895542b8fce929739… Using either of these branches, your circumvention session is decoupled from any single TCP connection. If a TCP connection is terminated, the obfs4proxy client will establish a new connection and pick up where it left off. An error condition is signaled to the higher-level application only when there's a problem establishing a new connection. Otherwise, transient connection termination is invisible (except as a brief increase in RTT) to Tor and whatever other application layers are being tunnelled. I did a small experiment showing how a Tor session can persist, despite the obfs4 layer being interrupted every 20 seconds. I configured the "little bastard" connection terminator to forward from a local port to a remote bridge, and terminate connections after 20 seconds. ``` lilbastard$ cargo run -- -w 20 127.0.0.1:3000 192.81.135.242:4000 ``` On the bridge, I ran tor using either plain obfs4proxy, or one of the two turbo tunnel branches. (I did the experiment once for each of the three configurations.) ``` DataDirectory datadir.server SOCKSPort 0 ORPort auto BridgeRelay 1 AssumeReachable 1 PublishServerDescriptor 0 ExtORPort auto ServerTransportListenAddr obfs4 0.0.0.0:4000 ServerTransportPlugin obfs4 exec ./obfs4proxy -enableLogging -unsafeLogging -logLevel DEBUG # ServerTransportPlugin obfs4 exec ./obfs4proxy.kcp -enableLogging -unsafeLogging -logLevel DEBUG # ServerTransportPlugin obfs4 exec ./obfs4proxy.quic -enableLogging -unsafeLogging -logLevel DEBUG ``` On the client, I configured tor to use the corresponding obfs4proxy executable, and connect to the bridge through the "little bastard" proxy. (If you do this, your bridge fingerprint and cert will be different.) ``` DataDirectory datadir.client SOCKSPort 9250 UseBridges 1 Bridge obfs4 127.0.0.1:3000 94E4D617537C3E3CEA0D1D6D0BC852B5A7613B77 cert=6rB8kVd981U0G2b9nXioB5o0Zu7tDpDkoZyPe2aCmqFzGmfaSiNIfQvkJABakH+DfYwWRw iat-mode=0 ClientTransportPlugin obfs4 exec ./obfs4proxy -enableLogging -unsafeLogging -logLevel DEBUG # ClientTransportPlugin obfs4 exec ./obfs4proxy.kcp -enableLogging -unsafeLogging -logLevel DEBUG # ClientTransportPlugin obfs4 exec ./obfs4proxy.quic -enableLogging -unsafeLogging -logLevel DEBUG ``` Then, I captured traffic for 90 seconds while downloading a video file through the tor proxy. In the "plain obfs4proxy" case, the download stopped after the first connection termination at 20 s. Every 20 s after that, there was a small amount of activity, which was tor reconnecting to the bridge (and the resulting obfs4 handshake). But it didn't matter, because tor has already signaled the first connection termination to the application layer, which gave up: ``` curl: (18) transfer closed with 111535615 bytes remaining to read ``` In comparison, the "kcp" and "quic" cases kept on downloading, being only momentarily delayed by a connection termination. Notes: * How this works architecturally, on the client side, we replace the original TCP Dial call with either kcp.NewConn2 or quic.Dial, over an abstract packet-sending interface (clientPacketConn). clientPacketConn runs a loop that repeatedly connects to the same destination and exchanges packets (represented as length-prefixed blobs in a TCP stream) as long as the connection is good, reporting an error only when a connection attempt fails. On the server side, we replace the TCP Listen call with either kcp.ServeConn or quic.Listen, over an abstract serverPacketConn. serverPacketConn opens a single TCP listener, takes length-prefixed packets from *all* the TCP streams that arrive at the listener, and feeds them into a *single* KCP or QUIC engine. Whenever we need to send a packet for a particular connection ID, we send it on the TCP stream that most recently sent us a packet for that connection ID. * There's no need for this functionality to be built into obfs4proxy itself. It could be done as a separate program: ``` ------------ client ------------ ------------ bridge ------------ tor -> turbotunnel -> obfs4proxy -> internet -> obfs4proxy -> turbotunnel -> tor ``` But this kind of process layering is cumbersome with pluggable transports. * I'm passing a blank client IP address to the pt.DialOr call—this information is used for geolocation in Metrics graphs. That's because an OR connection no longer corresponds to a single incoming IP address with its single IP address—instead it corresponds to an abstract "connection ID" that remains constant across potentially many TCP connections. In order to make this work, you would have to define some heuristic such as "the client IP address associated with the OR connection is that of the first TCP connection that carried that connection ID."

1 0

IPv6 Snowflake broker (#29258) IP addresses and SSH key fingerprints
by David Fifield 17 Oct '19

17 Oct '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 2019-10-17 This is a signed statement of the IP addresses and SSH host key fingerprints of the Snowflake broker set up by David Fifield at https://bugs.torproject.org/#comment:11. 37.218.245.111 2a00:c6c0:0:154:4:d8aa:b4e6:c89f RSA: 2048 SHA256:dp0Xo/oN1qZfMuZnqgKEbeOsbU2qpDR60B5MLIRaAgg DSA: 1024 SHA256:DF5ofogjGur02gv8/ciU3wFA+YHNuAhUlel9Uv2KBlo ECDSA: 256 SHA256:6cskO6ch/kv2RbIMhTdwqpsd9vB8npzlZTlkWZJLoek ED25519: 256 SHA256:fEkLvmu5woTvU6162I8Jxd2eHzsTnBshumtWICclWA4 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeXoyauxKR4rwUMw64rk9gVzTiOUFAl2ormoACgkQ4rk9gVzT iOX7xQ/+KyWHU7f5Oj2zFFVFu/vkD2xNIDEuPgnAUmVp879QnfzqmHxBifNzgpXQ t+357gSWlMAHP6IO0spnKxQqFsugvH3QqH5fyEXmEKQcJw7UI5VYNR5aGd7soSOx meHtgVkmeyWJDNZZSjVrk9C0nnEnteOXMx02NVD4kC1hJkSBvOJT4+M3Ekxx0nnQ AOfc7ZEBhchEMYsf2wxY04O0dR4HCgwcRFUGV+gT5bKw4eoqT+0sMetMzi5CHAqd EjsRQhDCHOp1v7xkkxx0lMOKPL4IYQI4l5qOIMWfpFS3ZwWX18bm3qK4UsDVAxIJ FouPEuVz7CAsLrlc5hnaDrmM2VsH8hqRFW4PHhmycaHVrW1AKkt0h/qHxDfpIkgK xGNbROcpzfV3FmqGWe09sx1aSLI34nMzIPX3aB6EmZ3Qn3Dx3VZExrBQSlcJ5NLy 3fFvqEpOhRheuE4ohD48/jfj0hsX/Sqc5cKNcmQFPbjk3T2LzUx8TYsNMq/Us0NC XrNk3ph5ydssMCLSEZqFV+xTY/08u6bKMYyxrC7bSsRJo1WIBLOVlWbHVYc6WGgD i/XCDMOXSFawZVIQm5PJiqR87y5q9RBnitd31uNnYZLlty3SFvj2H6PqSu7iIw46 I5Gc/rPxRcWggjOOXxCm0IiTqnM94WgoWWMRFNpQqHzTio+J6fc= =sJTV -----END PGP SIGNATURE-----

1 0

obfs4 bridge option on eclips.is
by David Fifield 14 Oct '19

14 Oct '19

While setting up a new VPS on eclips.is, which is the service we use to host the Snowflake broker and bridge, I noticed that they have a preconfigured option to set up an obfs4 bridge. (And an Outline server, which is the Shadowsocks-based VPN from Jigsaw.)

1 0