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