Apply
My Apply
My Apply

Research Corner: "The use of TLS in Censorship Circumvention"

This is a guest blog post by Sergey Frolov and Eric Wustrow, authors of “The use of TLS in Censorship Circumvention,” a paper analyzing real-world TLS client implementations of several popular censorship circumvention tools. Beyond analyzing existing issues with TLS in circumvention tools, the authors went on to develop a solution that helps make TLS traffic in circumvention tools less susceptible to blocking by allowing their implementation to "automatically mimic other popular TLS implementations."

By: Sergey Frolov and Eric Wustrow

In this post, we’ll describe our work to improve how circumvention tools blend in with normal Internet traffic, making them harder for censors to block. Our technical paper was published at the Network and Distributed Systems Security (NDSS) Symposium and presented in February 2019.

TLS and Censorship Circumvention

The Transport Layer Security (TLS) protocol is used to secure communication on the Internet and is commonly used by the HTTPS protocol to encrypt data between browsers and web servers (such as the one you are using right now). Because of its popularity, TLS is a good choice for censorship circumvention tools that want to blend in with other traffic online. Circumvention tools that use TLS include Lantern, Outline, Psiphon, TapDance, and Tor.

Censors are unlikely to block all TLS traffic because of its high popularity (and thus high collateral damage): over 75% of web pages loaded by Firefox use TLS. But just because a particular tool uses TLS doesn’t automatically make it immune from targeted blocking by a censor. Just like how different English speakers can have distinguishable accents while still speaking English, different TLS implementations can also have noticeable variances that allow censors to distinguish between them. Even though the protocol is encrypted, the first message the client sends in a TLS connection (the so-called “Client Hello” message) contains unencrypted options and features that the client supports. Different implementations support different features, and censors can use these differences to fingerprint implementations. Censors and DPI providers have previously used such fingerprints on multiple occasions to identify and block an uncommon fingerprint predominantly used by Tor.

Unique Fingerprints: Easy to ID, Easy to Block

To study how widespread this problem is, we looked at how different circumvention tools use TLS, and how they compare to other popular implementations of TLS like web browsers. We collected over 11 billion TLS connections that we observed at the University of Colorado Boulder over the course of 9 months, and used them to determine how popular the TLS fingerprints from circumvention tools were.

To our surprise, nearly every tool that we looked at used TLS in a unique way that could be vulnerable to blocking by censors. For example, Lantern’s TLS fingerprint was seen in less than 0.0003% of the TLS connections we collected, meaning it is relatively uncommon in typical traffic. This means there is little collateral damage for a censor to block Lantern’s TLS connections, because almost nothing else looks or sounds like it on the Internet. Our paper has more details, but in short, besides Lantern, we found issues with Psiphon, Snowflake, and Signal that would allow censors to easily identify and block their TLS connections.

Fixing the Problem

To correct this issue, we developed a TLS library, which we call uTLS, that makes it easier for developers to generate TLS connections with specific fingerprints. For example, with uTLS, a circumvention tool can make their TLS connections look like one produced by Chrome 71+, currently the most popular TLS fingerprint we observe which is used by over 18% of connections on our university campus. This makes it easy for developers to mimic popular TLS implementations, and harder for censors to block using TLS fingerprints. In addition, the library allows developers to generate randomized fingerprints which can evade censors that attempt to block specific fingerprints.

We notified all the affected tools of our findings and shared with them the new uTLS library. So far, developers of Lantern, Psiphon, TapDance, and Tor have integrated our uTLS library into their client software, fixing the original problem we identified and making it easier to mimic new TLS implementations in the future.

We also developed a website (tlsfingerprint.io) that lets developers upload the Packet Capture (PCAP) files of their own tool’s TLS connection, and compare them to our collected fingerprints, to quickly determine if their tool is at risk. Developers can also use the website to look for popular fingerprints and other TLS features that they may want to mimic. The website can also automatically generate uTLS configuration code that developers can copy-paste to quickly mimic new, popular implementations as they emerge. That’s especially important as fingerprint popularity can quickly change over time as new versions and implementations are released. The website also tracks clusters of TLS fingerprints, popular TLS extensions and cipher suites, session ticket sizes, and many other TLS features useful for circumvention and general statistics.

Looking Forward

We hope that our library and website are useful for censorship circumvention tool developers going forward (and excited that it is already benefiting real users!). As the censorship arms race continues to escalate over the years, we are cautiously optimistic to be one step ahead of the censors. We plan to continue maintaining our library and website to benefit as many tools as possible and welcome community contributions to our library. We also would like to thank contributors from the anti-censorship community, including Google's Jigsaw and Psiphon, whose support has been instrumental to the success of this project.


This blog post is part of OTF's Research Corner blog series, where we highlight interesting research relevant to Internet freedom on topics such censorship, circumvention tool development, and security analysis, for example. Note that the research we feature here was not supported with OTF funding and does not constitute an endorsement of any of its findings or technologies, but is recapped here in an effort to further connect such research efforts with the broader Internet freedom community.

If you have research of your own you’d like to see featured through OTF’s Research Corner, send us an email at [email protected]