- anti-censorship-team - lists.torproject.org

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

Summary of Point Break (Jansen et al. USENIX Security '19) as it pertains to bridges
by David Fifield 26 Aug '19

26 Aug '19

Rob Jansen, Tavish Vidya, and Micah Sherr have a paper about bandwidth-based DoS against Tor. Section 5 is about default bridges. https://www.usenix.org/conference/usenixsecurity19/presentation/jansen https://www.usenix.org/system/files/sec19-jansen.pdf#page=6 While elsewhere in the paper they discuss in-protocol attacks, in the context of bridges they limit themselves to attacks using third-party paid "stresser" DoS services, which you can rent for about $1/Gbps/hour (Section 3.1). They looked at the default bridges in Tor Browser 8.0.3 (October 2018). Only 12 of 25 default obfs4 bridges were working. (I think most of the non-working bridges have since been pruned, e.g. in #29378, #30264.) The median bandwidth of the 12 working bridges was 368 KB/s, with a large variance: minimum of 67 KB/s and maximum of 1190 KB/s. Besides the default bridges, they requested 135 bridges from BridgeDB, and found that only 70% (95/135) of them worked. (This has also been at least partially addressed by #30441.) BridgeDB bridges are faster than default bridges, with a median bandwidth of closer to 600 KB/s (Figure 1). They estimate that disabling the 12 default obfs4 bridges would require 30 stresser jobs, at a rate of $22/hour or $17K/month. If all users of default obfs4 bridges switched to BridgeDB bridges, the median bandwidth of BridgeDB bridges would slow down to under 100 KB/s (Figure 2). If even half of default obfs4 users switch to using meek, the cost to operate meek will at least double (Figure 3).

3 3

Turbo Tunnel: let's build a sequencing/reliability layer into our circumvention protocols
by David Fifield 16 Aug '19

16 Aug '19

I've just posted a manifesto on circumvention protocol design at the net4people BBS: https://github.com/net4people/bbs/issues/9 I'll include the text here as well. Code name: Turbo Tunnel Designing circumvention protocols for speed, flexibility, and robustness In working on circumvention protocols, I have repeatedly felt the need for a piece that is missing from our current designs. This document summarizes the problems I perceive, and how I propose to solve them. In short, I think that every circumvention transport should incorporate some kind of session/reliability protocol—even the ones built on reliable channels that seemingly don't need it. It solves all kinds of problems related to performance and robustness. By session/reliability protocol, I mean something that offers a reliable stream abstraction, with sequence numbers and retransmissions, like [QUIC](https://quicwg.org/) or [SCTP](https://tools.ietf.org/html/rfc4960#section-1.5.2). Instead of a raw unstructured data stream, the obfuscation layer will carry encoded datagrams that are provided by the session/reliability layer. When I say that circumvention transports should incorporate something like QUIC, for example, I don't mean that QUIC UDP packets are what we should send on the wire. No—I am not proposing a new *outer* layer, but an additional *inner* layer. We take the datagrams provided by the session/reliability layer, and encode them as appropriate for whatever obfuscation layer we happen to be using. So with meek, for example, instead of sending an unstructured blob of data in each HTTP request/response, we would send a handful of QUIC packets, encoded into the HTTP body. The receiving side would decode the packets and feed them into a local QUIC engine, which would reassemble them and output the original stream. A way to think about it is that the the sequencing/reliability layer is the "TCP" to the obfuscation layer's "IP". The obfuscation layer just needs to deliver chunks of data, on a best-effort basis, without getting blocked by a censor. The sequencing/reliability layer builds a reliable data stream atop that foundation. I believe this design can improve existing transports, as well as enable new transports that are now possible now, such as those built on unreliable channels. Here is a list of selected problems with existing or potential transports, and how a sequencing/reliability layer helps solve them: Problem: Censors can disrupt obfs4 by terminating long-lived TCP connections, as Iran did in 2013, killing connections after 60 seconds. This problem exists because the obfs4 session is coupled with the TCP connection. The obfs4 session begins and ends exactly when the TCP connection does. We need an additional layer of abstraction, a virtual session that exists independently of any particular TCP connection. That way, if a TCP connection is terminated, it doesn't destroy all the state of the obfs4 session—you can open another TCP connection and resume where you left off, without needing to re-bootstrap Tor or your VPN or whatever was using the channel. Problem: The performance of meek is limited because it is half-duplex: it never sends and receives at the same time. This is because, while the bytes in a single HTTP request arrive in order, the ordering of multiple simultaneous requests is not guaranteed. Therefore, the client sends a request, then waits for the server's response before sending another, resulting in a delay of an RTT between successive sends. The session/reliability layer provides sequence numbers and reordering. Both sides can send data whenever is convenient, or as needed for traffic shaping, and any unordered data will be put back in order at the other end. A client could even split its traffic over two or more CDNs, with different latency characteristics, and know that the server will buffer and reorder the encoded packets to correctly recover the data stream. Problem: A Snowflake client can only use one proxy at a time, and that proxy may be slow or unreliable. Finding a working proxy is slow because each non-working one must time out in succession before trying another one. The problem exists because even though each WebRTC DataChannel is reliable (DataChannel uses SCTP internally), there's no ordering between multiple simultaneous DataChannels on separate Snowflake proxies. Furthermore, if and when a proxy goes offline, we cannot tell whether the last piece of data we sent was received by the bridge or not—the SCTP ACK information is not accessible to us higher in the stack—so even if we reconnect to the bridge through another proxy, we don't know whether we need to retransmit the last piece of data or not. All we can do is tear down the entire session and start it up again from scratch. As in the obfs4 case, this problem is solved by having an independent virtual session that persists across transient WebRTC sessions. An added bonus is the opportunity to use more than one proxy at once, to increase bandwidth or as a hedge against one of them disappearing. Problem: [DNS over HTTPS](https://groups.google.com/d/msg/traffic-obf/ZQohlnIEWM4/09N7zsxjBgAJ) is an unreliable channel: it is reliable TCP up to the DoH server, but after that, recursive resolutions are plain old unreliable UDP. And as with meek, the ordering of simultaneous DNS-over-HTTPS requests is not guaranteed. Solved by retransmission in the session layer. There's no [DNS pluggable transport](https://trac.torproject.org/projects/tor/wiki/doc/DnsPluggableTr… yet, but I think some kind of retransmission layer will be a requirement for it. Existing DNS tunnel software uses various ad-hoc sequencing/retransmission protocols. I think that a proper user-space reliability layer is the "right" way to do it. Problem: Shadowsocks opens a separate encrypted TCP connection for every connection made to the proxy. If a web page loads resources from 5 third parties, then the Shadowsocks client makes 5 parallel connections to the proxy. This problem is really about multiplexing, not session/reliability, but several candidate session/reliability protocols additionally offer multiplexing, for example streams in QUIC, streams in SCTP, or smux for KCP. Tor does not have this problem, because Tor already is a multiplexing protocol, with multiple virtual circuits and streams in one TCP/TLS connection. But every system could benefit from adding multiplexing at some level. Shadowsocks, for example, could open up one long-lived connection, and each new connection to the proxy would only open up a new stream inside the long-lived connection. And if the long-lived connection were killed, all the stream state would still exist at both endpoints and could be resumed on a new connection. As an illustration of what I'm proposing, here's the protocol layering of meek (which [sends chunks of the Tor TLS stream](https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPl… inside HTTP bodies), and where the new session/reliability layer would be inserted. Tor can remain oblivious to what's happening: just as before it didn't "know" that it was being carried over HTTP, it doesn't now need to know that it is being carried over QUIC-in-HTTP (for example). ``` [TLS] [HTTP] [session/reliability layer] ⇐ 🆕 [Tor] [application data] ``` I've done a little survey and identified some suitable candidate protocols that also seem to have good Go packages: * [QUIC](https://quicwg.org/) with [quic-go](https://github.com/lucas-clemente/quic-go) * KCP with [kcp-go](https://github.com/xtaci/kcp-go) * [SCTP](https://tools.ietf.org/html/rfc4960) with [pion/sctp](https://github.com/pion/sctp) I plan to evaluate at least these three candidates and develop some small proofs of concept. The overall goal of my proposal is to liberate the circumvention context from particular network connections and IP addresses. ### Related work The need for a session and sequencing layer has been felt—and dealt with—repeatedly in many different projects. It has not yet, I think, been treated systematically or recognized as a common need. Systems typically implement some form of TCP-like SEQ and ACK numbers. The ones that don't, are usually built on the assumption of one long-lived TCP connection, and therefore are really using the operating system's sequencing and reliability functions behind the scenes. Here are are few examples: * Code Talker Tunnel (a.k.a. SkypeMorph) uses [SEQ and ACK numbers](https://www.cypherpunks.ca/~iang/pubs/skypemorph-ccs.pdf#page=7) and mentions selective ACK as a possible extension. I think it uses the UDP 4-tuple to distinguish sessions, but I'm not sure. * OSS used [SEQ and ACK numbers](https://www.freehaven.net/anonbib/papers/pets2013/paper_29.pdf#pag… and a random ID to distinguish sessions. * I [wasted time](https://www.bamsoftware.com/papers/thesis/#p227) in the early development of meek grappling with sequencing, before [punting by strictly serializing requests](https://www.bamsoftware.com/papers/fronting/#sec:deploy-tor), sacrificing performance for simplicity. meek uses an [X-Session-Id](https://trac.torproject.org/projects/tor/wiki/doc/AChildsGard… HTTP header to distinguish sessions. * [DNS tunnels](https://trac.torproject.org/projects/tor/wiki/doc/DnsPluggableTran… all tend to do their own idiosyncratic thing. dnscat2, one of the better-thought-out ones, uses [explicit SEQ and ACK numbers](https://github.com/iagox86/dnscat2/blob/master/doc/protocol.md#seq…. My position is that SEQ/ACK schemes are subtle enough and independent enough that they should be treated as a separate layer, not as an underspecified and undertested component of some specific system. Psiphon can use [obfuscated QUIC](https://github.com/Psiphon-Labs/psiphon-tunnel-core/tree/52de11dbabae… as a transport. It's directly using QUIC UDP on the wire, except that each UDP datagram is [additionally obfuscated](https://github.com/Psiphon-Labs/psiphon-tunnel-core/blob/52de11… before being sent. You can view my proposal as an extension of this design: instead of always sending QUIC packets as single UDP datagrams, we allow them to be encoded/encapsulated into a variety of carriers. [MASQUE](https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html#RFC8441) tunnels over HTTPS and can use QUIC, but is not really an example of the kind of design I'm talking about. It leverages the multiplexing provided by HTTP/2 (over TLS/TCP) or HTTP/3 (over QUIC/UDP). In HTTP/2 mode it does not introduce its own session or reliability layer (instead using that of the underlying TCP connection); and in HTTP/3 mode it directly exposes the QUIC packets on the network as UDP datagrams, instead of encapsulating them as an inner layer. That is, it's using QUIC as a carrier for HTTP, rather than HTTP as a carrier for QUIC. The main similarity I spot in the MASQUE draft is the envisioned [connection migration](https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html#rfc.section.7.1) which frees the circumvention session from specific endpoint IP addresses. Mike Perry wrote a [detailed summary](https://lists.torproject.org/pipermail/tor-dev/2018-March/013026.h… of considerations for migrating Tor to use end-to-end QUIC between the client and the exit. What Mike describes is similar to what is proposed here—especially the subtlety regarding protocol layering. The idea is not to use QUIC hop-by-hop, replacing the TLS/TCP that is used today, but to *encapsulate* QUIC packets end-to-end, and use some other *unreliable* protocol to carry them hop-by-hop between relays. Tor would not be using QUIC as the network transport, but would use features of the QUIC protocol. ### Anticipated questions Q: Why don't VPNs like Wireguard have to worry about all this? A: Because they are implemented in kernel space, not user space, they are, in effect, using the operating system's own sequencing and reliability features. Wireguard just sees IP packets; it's the kernel's responsibility to notice, for example, when a TCP segment need to be retransmitted, and retransmit it. We should do in user space what kernel-space VPNs have been doing all along! Q: You're proposing, in some cases, to run a reliable protocol inside another reliable protocol (e.g. QUIC-in-obfs4-in-TCP). What about the reputed inefficiency TCP-in-TCP? A: Short answer: don't worry about it. I think it would be premature optimization to consider at this point. The fact that the need for a session/reliability layer has been felt for so long by so many systems indicates that we should start experimenting, at least. There's contradictory information online as to whether TCP-in-TCP is as bad as they say, and anyway there are all kinds of performance settings we may tweak if it turns out to be a problem. But again: let's avoid premature optimization and not allow imagined obstacles to prevent us from trying. Q: QUIC is not just a reliability protocol; it also has its own authentication and encryption based on TLS. Do we need that extra complexity if the underlying protocol (e.g. Tor) is already encrypted and authenticated independently? A: The transport and TLS parts of QUIC are specified separately (https://tools.ietf.org/html/draft-ietf-quic-transport and https://tools.ietf.org/html/draft-ietf-quic-tls), so in principle they are separable and we could just use the transport part without encryption or authentication, as if it were SCTP or some other plaintext protocol. In practice, quic-go [assumes](https://godoc.org/github.com/lucas-clemente/quic-go#Dial) right in the API that you'll be using TLS, so separating them may be more trouble than it's worth. Let's start with simple layering that is clearly correct, and only later start breaking abstraction for better performance if we need to. Q: What about traffic fingerprinting? If you simply obfuscate and send each QUIC packet as it is produced, you will leak traffic features through their size and timing, especially when you [consider retransmissions and ACKs](https://www-users.cs.umn.edu/~hoppernj/ccs13-cya.pdf#page=5). A: Don't do that, then. There's no essential reason why the traffic pattern of the obfuscation layer needs to match that of the sequencing/reliability layer. Part of the job of the obfuscation layer is to erase such traffic features, if doing so is a security requirement. That implies, at least, *not* simply sending each entire QUIC packet as soon as it is produced, but padding, splitting, and delaying as appropriate. An ideal traffic scheduler would be *independent* of the underlying stream—its implementation would [not even *know*](https://lists.torproject.org/pipermail/tor-dev/2017-June/012310.html) how much actual data is queued to send at any time. But it's likely we don't have to be quite that rigorous in implementation, at least at this point.

2 2

tor and umts
by Stefan Kuttler 13 Aug '19

13 Aug '19

https://stackoverflow.com/questions/57268523/care-for-privacy-encrypted-bro…

1 0

tor and umts
by Stefan Kuttler 13 Aug '19

13 Aug '19

https://stackoverflow.com/questions/57268523/care-for-privacy-encrypted-bro…

1 0

Best (simple) obfs4 deployment url?
by Roger Dingledine 06 Aug '19

06 Aug '19

Hi Philipp! I am finishing up my Defcon slides, and I realized I don't know where to point people for setting up obfs4 bridges. Google sends me to https://support.torproject.org/operators/operators-6/ but I bet that's not up-to-date (but maybe it should become up-to-date). On the tor-relays list I see https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4… which is (a) a really long url, and (b) an intimidatingly long page. And I hear irl is working a 'tor-bridge' meta-deb: https://bugs.torproject.org/31153 So: assuming I want to tell a bunch of people to do something in a week and a half, using a url they can hastily scribble down from my slide, what should I tell them? :) It is ok if the url doesn't say the right thing today but we're confident it will say the right thing on the morning of Aug 8. Thanks, --Roger

2 3

The MASQUE circumvention protocol
by Philipp Winter 31 Jul '19

31 Jul '19

I found a more extensive description of the MASQUE protocol: <https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html> Here are my key take-aways after reading the draft: * MASQUE enables circumvention by hiding a circumvention proxy behind a web server, similar to Sergey's httpsproxy. Clients "unlock" the web server's circumvention feature by using the newly-proposed HTTP Transport Authentication Standard: <https://tools.ietf.org/html/draft-schinazi-httpbis-transport-auth-00> In a nutshell, clients need to send a CONNECT request with a transport authentication header to .well-known/masque/initial. Crucially, MASQUE defends against active probing by responding with "405 Method Not Allowed" to failed authentication attempts -- the same response one would get for an unexpected CONNECT request. This prevents censors from learning if a web server supports MASQUE. * Once a client "unlocked" a MASQUE server, one can tunnel several types of traffic over the MASQUE server. One can use it as an HTTP proxy, send DNS requests, and do both UDP and TCP proxying. * MASQUE supports QUIC over HTTP/3 and TLS 1.3 over HTTP/2. There is a fallback mechanism from HTTP/3 to HTTP/2 to provide a disincentive for censors to block QUIC or HTTP/3. * MASQUE only provides obfuscation and does not provide anonymity. The document suggests onion routing in Section 2.4 to work around this shortcoming. * MASQUE does not defend against traffic analysis but QUIC supports padding, so there's a mechanism to mitigate this problem. Traffic analysis defence is left for future work in Section 7.2. * QUIC has a "connection migration" feature that allows clients to seamlessly switch end-to-end connections from one MASQUE server to another. * Similar to onion services, MASQUE makes it possible to make available a server behind NAT by using a MASQUE server as a rendez-vous mechanism. There's an IETF mailing list for the project: <https://mailarchive.ietf.org/arch/browse/masque/> MASQUE may make a good pluggable transport and we should engage early to make this happen. I intend to suggest this idea on their mailing list soon. Cheers, Philipp

1 0

Resources related to user testing and screen recording
by David Fifield 14 Jul '19

14 Jul '19

These are in response to a conversation with phw and cohosh about observing how people use Tor Browser. Here are links relating to the 2015 UX Sprint, at which we did one-on-one observations of a few users. https://blog.torproject.org/ux-sprint-2015-wrapup https://trac.torproject.org/projects/tor/wiki/org/meetings/2015UXsprint The videos of the sessions are here: https://people.torproject.org/~dcf/uxsprint2015/ The source code for our screen recording setup is here. I'm attaching the README. https://www.bamsoftware.com/git/repo.eecs.berkeley.edu/tor-ux.git Here's a rough description of the whole process. We ran user experiments over two days. We were hampered by late recruiting (Berkeley only approved the experiment literally the day before) and we only had five participants, three on Saturday and two on Sunday. But that number turned out to be plenty because of how labor-intensive the process was. We had all the devs in a room downstairs with a projector. The experiments were run upstairs in a smaller room on a laptop. What we did was screencast the laptop screen to the projector downstairs (using VLC streaming through an SSH tunnel). Developers could watch user interactions live, and we also recorded the whole thing. We audio recorded the subjects' voices on handheld audio recorders (we encouraged them to think out loud as they were using the software). The idea was to transcribe the audio and add it to the screen recordings as subtitles. That was a huge amount of work, but the videos are really interesting and enlightening. We gave participants the choice of a Windows or Mac laptop. It happens that all of the chose Mac, though we had Windows ready to go. Windows was a big pain to set up with VLC and SSH; I might do that differently a second time. We originally planned to run up to two experiments simultaneously. That would have been way too hectic. It's a lot of work greeting people, doing paperwork, doing the experiment, making sure you reset the computer in between experiments--we really needed an extra person downstairs all that time. With more researchers (i.e., people allowed to interact with participants) it would be possible. We budgeted one hour of one-on-one time with each participant. It ended up taking between 15 and 30 minutes of actual experiment for each (that's how long the resultant videos are), but that doesn't count all the paperwork and setup time. 60 minutes of actual experiment would have been too long. It could be that long if it were not one on one. But also, there was high variance in how long things took to complete. Some users took longer to install than others. Another took a long time trying to find a specific UI element. The repo for our PETS 2017 paper is here: https://github.com/lindanlee/PETS2017-paper The screen capture videos from a pilot session of recording are here: https://github.com/lindanlee/PETS2017-paper/tree/master/sessions/pre/videos Scripts relating to setting up the simulated censorship firewall are here: https://github.com/lindanlee/PETS2017-paper/tree/master/experiment

1 0

"Dissecting Tor Bridges" NDSS'17 paper
by Philipp Winter 09 Jul '19

09 Jul '19

I skimmed Matic et al.'s NDSS'17 paper "Dissecting Tor Bridges: a Security Evaluation of Their Private and Public Infrastructures": <https://censorbib.nymity.ch/pdf/Matic2017a.pdf> Below are the points that stood out the most to me. Note however that the study is from 2017 and some numbers may no longer be valid. * With the exception of China and the U.S., default bridges served by far the most users. The popularity of default bridges makes them a single point of failure that is easy for censors to block. We have been losing default bridges over the last few months and should be recruiting new operators: <https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges> We have a list of criteria for new operators at the bottom of the page. If you are interested in running a default bridge, please get in touch. * Four OR ports (443, 8443, 444, and 9001) were used much more often than others. Today, 19% of bridges use port 9001 and 17% use port 443. Port 9001 is problematic because it is an attractive target for Internet-wide scans. So is port 443 but it has some merit for users who seek to circumvent corporate firewalls. Is there any reason at all to have bridges listen on port 9001? If not, we should ask these operators to pick a new port. * If a censor discovers a bridge and the bridge runs an SSH server, the censor can fetch its fingerprint and use Shodan to find other SSH servers with the same fingerprint. These servers may also be running bridges. Bridge-specific SSH keys would fix this problem. We may want to create a "bridge opsec guide" for subtle issues like these. * Shodan and Censys are search engines for Internet-wide scans. The authors were successful in using these datasets to find 35% of "public" bridges, i.e., bridges that publish their server descriptor to the bridge authority. The idea is to look for certificates that resemble a Tor bridge and then actively probe the port to confirm this suspicion. This is a tricky balancing act: most bridges should probably avoid the ports that Shodan and Censys scan but we need a few of them for users whose firewalls whitelist these ports. * Many bridges run transports that are both resistant *and* vulnerable to the GFW's active probing attacks. The vulnerable protocols are a liability to the resistant protocols. We fixed this issue in BridgeDB (#28655) but it remains a problem for Internet-wide scans: if a censor discovers a bridge via a port 9001 scan, obfs4's probing-resistance doesn't help. The need to haven an open OR port (#7349) remains a painful issue. Also, wouldn't it be useful to have a mechanism to instruct bridges to stop serving a transport? At this point, there is no reason to still serve obfs2, obfs3, or ScrambleSuit. Cheers, Philipp

1 0

2024

2023

2022

2021

2020

2019

anti-censorship-team