okTurtles, DNSChain, and Unblock.us.org form a software stack that is being sold as a panacea to online surveillance and DNS censorship. This hyperbolic marketing is disingenuous if not dangerous. I would like to outline exactly what each piece of software does and how the stack relates to the field as a whole.
okTurtles and DNSChain make fantastic claims about some very vanilla software, such as being impervious to MITM attacks, fixing HTTPS, and that their third party trust system “is at least as good as lightweight [clients].” They believe that a transparent HTTPS proxy, Unlock.us, is immune to DPI and thus “short of cutting entire countries off the internet, DNSChain/Unblock.us will be able to get through.”
Blockchain technology has the potential to make a significant impact on the usability of encryption and anonymity networks. Unfortunately, okTurtles and DNSChain consistently misapplies this technology. okTurtles is a end-to-end encryption client that is vulnerable to MITM attacks and advertises an impossibly good user experience. DNSChain doesn’t fix HTTPS generally and they are pushing a 3rd party trust system that needlessly breaks the key MITM protection offered by blockchains. Unblock.us isn’t immune to traffic analysis and isn’t safe for use in countries that block commercial VPNs and proxies.
I’m writing this because misleading users about security and anonymity software can have dangerous consequences. Tor’s lead developer once relayed an anecdote about an Iranian Tor user who taught fellow political dissidents how to use censorship circumvention software. At some point, the user realized that the people whom he had trained to use Tor were still around and everyone using something else was in prison. This is the reality for security-related software projects and their marketing claims should be held to a very high standard.
- “MITM-proof communication through almost any website, with zero intervention needed from the site operators.”
- “… it will stop all of the publicly known methods by which the NSA can read your messages on these sites via a MITM attack.1”
- “… true end-to-end encryption and authentication between you and the person you’re communicating with that does not fall prey to … interception, redirection, and/or tampering-with of the communication in question.”
- “… making this surveillance simply irrelevant.”
- okTurtles is an end-to-end (E2E) encryption client for online platforms, such as Facebook and Twitter.
- It is inherently vulnerable to MITM attacks by service providers.
- It cannot effectively mitigate UI spoofing attacks without crippling usability.
okTurtles advertises an impossibly good user experience that is not “MITM-proof.” Trying to bolt an E2E client onto a website opens okTurtles up to a range of attacks that are not true of other messaging systems: UI spoofing. A service provider can spoof okTurtles interface, tricking the user to enter text into a text field they can read, save a copy of the plaintext, and forward an encrypted version to the recipient. With closed loop systems like Facebook, they can detect if both sides use okTurtles and spoof message decryption and verification on both ends.
Websites are Turing complete programs and logging into a web platform allows the service provider to serve a malicous version of their web client. The service provider can spoof the okTurtles interface, the identity of the user, contextual menus, and even manipulate copy and paste commands. The only way to mitigate these attacks is to move the contact list, the text entry field, the new message button, and the reply button outside of the website. This negates nearly all of the usability benefits promised by okTurtles.
Messaging software itself can be backdoored, but we can at least turn to deterministic compilation and security audits to increase the cost of such an attack (and few claim to be “MITM-proof”). Not only is this not possible on web platforms, it’s trivial for service providers to precisely target victims, detect if the user has okTurtles installed, and deliver a new payload every time a user logs in. Unlike email, Facebook and other service providers have total control of the messaging system. I’m also wary of relying on the browser’s same-origin-security policy to protect our private communications and encryption keys. The browser is a very hostile environment to try and build secure software in and trust in the service provider should be assumed.
Browser-based E2E encryption is still potentially useful. It raises the cost of an attack, it forces service providers to actively participate in serving backdoored versions of their sites, and it may add additional legal hurdles. Using blockchains to specify identities is more usable than selecting public keys and is resistant to a specific type of MITM attack. If okTurtles only claimed to provide protection against dragnet surveillance or modest improvements to usability, I would have no issue with the software. But okTurtles advertises it for use by human rights workers and journalists and claims that “… it will stop all of the publicly known methods by which the NSA can read your messages on these sites via a MITM attack.”
Furthermore, okTurtles wants to make it easy for others to write plugins to support other web platforms. Journalists and human rights workers might be comfortable trusting TAILS and Thunderbird developers to resist governmental pressure to deliver an update with a backdoor. You might even be willing to trust Google or Facebook not spoof the UI, but I fear that someone will take their “MITM-proof” claims seriously and port the software for use on Weibo or vKontakte.
If okTurtles sold itself as a more usable E2E client, as Mailvelope does, I would not have a problem with the software. But okTurtles is advertising an impossibly good user experience that is trivially vulnerable to UI spoofing. A browser add-on could be built that is resistant to UI spoofing, but it cannot integrate with the web client’s interface directly. The result will probably be a few notches above copying and pasting the ciphertext manually and it certainly won’t be as usable as dedicated messaging software. okTurtles might be a step forward, but it will not “make surveillance simply irrelevant” and their UI mockups and security claims are dishonest.
- “HTTPS is broken. DNSChain fixes it.”
- “MITM-proof’ed Internet connections.”
- “DNSChain now has a 3-pronged security model that is at least as good as [lightweight clients]2”
- DNSChain is middleware, primarily a DNS server and a REST API that retrieves information from a blockchain.
- DNSChain does nothing to fix HTTPS for 99.99%+ of domains.
- They are pushing 3rd party trust solution that breaks the MITM protections provided by blockchains.
- Their security is inferior to lightweight clients.
DNSChain’s derives its security benefits from Namecoin and similar cryptocurrencies. Cryptocurrencies can prevent MITM attacks against faulty DNS and TLS information for specific top-level domains. DNSChain does nothing to protect 99% of top level domains (such as .com or .net) and it does not fix HTTPS generally.
Indeed, DNSChain doesn’t have much to do with the protections it derives from using blockchains, such as Namecoin. The following feature matrix is copied from DNSChain’s Github repo, but it specifies which component provides the claimed feature.
|Feature||Provided by Component|
|MITM-proof’ed Internet connections (for specific blockchain TLDs)||Blockchain|
|GPG key distribution||Blockchain|
|RESTful API to blockchain||DNSChain|
|Free and actually-secure SSL certificates||Blockchain|
|Stops many denial-of-service attacks||Not really/Blockchain3|
|Certificate revocation that actually works||Not really/Blockchain4|
|DNS-based censorship circumvention||Unblock.us|
|Prevents domain theft (“seizures”)||Blockchain|
|Access to Blockchain TLDs||Blockchain|
DNSChain was initially a pure client/server model which they advertised as “MITM-proof.” After receiving pushback on this, they added two features: checking multiple DNSChain servers and public key pinning (“Proof-of-Transition”). But this is nothing new: checking multiple peers and storing cryptographic information from the first connection are as old a cryptography itself. Moxie Marlinspike was a pioneer in building systems similar to what DNSChain is proposing for HTTPS, such as Convergence and Tack. However, neither of Marlinspike’s projects claim to be “MITM-proof” and DNSChain breaks MITM protections offered by blockchain technology.
Slepak (DNSchain’s lead developer) claims that DNSChain’s client/server model is “at least as good as” lightweight resolvers. This is simply not true and demonstrates a basic ignorance of lightweight technology, which can preserve the full MITM protections offered by the Nakamoto blockchain5.
Update DNSChain’s lead author followed up with a claim that, “If I run DNSChain at home or on my server, it’s equivalent to the security a full node would provide me with, and that’s superior to lightweight clients.”6
This “user running a server” configuration is a fictitious use case. As I explained in my first DNSChain blog post, this is equivalent to claiming everyone will run their own email server. Thus, for 99% of users, DNSChain is a third party trust solution. Slepak basically agreed with this analysis but claimed that everyone would buy a PlugPC that would function as their server. In my second DNSChain blogpost I explained why this would never scale and how it locks us into trusting the PlugPC manufacturer.
The primary Namecoin lightweight resolver (which I will call a UNO resolver) has storage requirements that are less than that of a Bitcoin SPV client while offering security more akin to a Bitcoin UTXO client. Name-only resolvers do not need to worry about double spends, so they only need to store a few dozen megabytes of block headers. Because name-only resolvers only need to store headers for current names, their storage requirements do not increase over time. Furthermore, special data structures can be used to validate responses from full nodes, so there is no need to contact multiple servers.
An attacker with 50% of the network hashing power could trick a UNO resolver into accepting an old (but still valid) DNS record for 2 hours every few weeks. I don’t know how much it costs to attack a DNSChain server, but it is certainly less than a 51% attack. And for the 1% of users that can administer their own Namecoin full node, their UNO resolver could be configured to connect to their full node client. No matter how you slice it, DNSChain’s third party trust system isn’t as secure as a UNO resolver.
Slepak is pushing this system because he believes that is more practical alternative to lightweight resolvers. If you are willing to accept third party trust, threshold DNSSEC makes a similar compromise for blockchain based TLDs but offers a sane path to backwards compatibility. However, lightweight resolvers are more usable than a DNSChain client because they do not require any configuration. In terms of storage requirements and network performance, the differences between the two solutions are negligible even on mobile devices.
Slepak asserts that lightweight resolvers won’t work on iOS devices because iOS devices cannot share data between apps. Downloading headers only amounts to about 220 KiB per day and they can be fetched preemptively or even pushed to the device. Even if the lightweight resolver has to fetch some headers, it doesn’t have to query multiple servers, like a DNSChain client would.
When it comes to storage requirements, even the prospect of supporting multiple blockchains isn’t a big deal. I can imagine a future where there are 5 relevant blockchain identity providers and maybe 3 blockchain based TLDs worth supporting. Over the past 7 years, the minimum iOS storage capacity has quadrupled from 4GB to 16GB. Assuming linear increases in storage capacity over another 7 years, an app supporting name resolution for 5 different blockchains will take up <1% of an iOS device’s storage capacity.
Slepak also tries to make hay of the fact that lightweight resolvers are still a ways off from being complete, but so is DNSChain. For Namecoin and Bitcoin, the necessary core changes are probably less than a year away. Shoring up DNSChain’s third party trust system and building out all of the infrastructure needed to support it leeches funding and developers from solutions that offer something better than the status quo. After all, if a blockchain identity solution cannot offer something better than third party trust, why would it succeed where Microsoft, Google, and other commercial entities have failed?
If DNSChain simply sold itself as middleware with a trusted server option that can support multiple blockchains, I wouldn’t have a problem with it. But DNSChain keeps pushing a security model that breaks the MITM protections offered by the Nakamoto blockchain and unnecessarily ties itself to third party trust. Lightweight resolvers are more secure and practical even on mobile devices. Finally, the DNSChain team has a track record for making deceptive claims, such as “fixing HTTPS” when they impact less than 1% of domains or being “MITM-proof” despite being a third party trust solution for 99% of users.
- “DNSChain’s censorship circumvention is in many ways superior to Tor’s!”
- “…[Unblock.us is] indistinguishable from TLS and immune to DPI.”
- “Short of cutting entire countries off the internet, DNSChain/Unblock.us will be able to get through.”
- Unblock.us is a HTTP proxy that is only used if a website is blocked.
- A censor can detect and block Unblock.us proxies without shutting off the entire internet.
- Circumventing censorship is trivial, scaling censorship circumvention is really hard.
- Unblock.us does not materially advance circumvention technology.
The official Unblock.us project is actually fairly responsible in the claims that they make; the above quotes are pulled from DNSChain’s Github repository and comments made by DNSChain’s lead developer. However, statements about it being “superior to Tor” and being immune to DPI aren’t just misleading, they are dangerous.
It is trivial to detect and block Unblock.us. Their routing (unencrypted SNI headers) currently leaves the domain name visible, but they have proposed a fix which obfuscates the domain name. The technical description of the fix makes it sounds as if the obfuscated domain could be detected using pattern matching. Even if we assume that they code specific unblocked domains to stand in for blocked domains (thus avoiding pattern matching) the unblocked domain name wouldn’t normally resolve to the proxy. Even if they make a system in which the censor cannot be absolutely sure that it is a proxy, they can simply throttle the connection and make it unusable. We could play a few more rounds of this cat-and-mouse game, but the point is that Unblock.us is not immune to traffic analysis.
Slepak claims that using HTTPS makes Unblock.us indistinguishable from other traffic. However, Tor also tries to hide its traffic as vanilla HTTPS, but they do not claim that their protocol is indistinguishable from HTTPS traffic. This is what Jacob Appelbaum has to say about such claims,
One really important point here is that we are extremely clear about the fact that Tor is not a stenographic transport…. We don’t make that claim because people who make that claim are full of shit.
There are hundreds of researchers working on circumvention technologies. Searching for “Tor” on Google scholar pulls up over 3,000 research papers. This is also a major industry: one major VPN service provider has 4 million in annual revenue and the DoD would love to have a stenographic transport for their military and covert operations. In the twelve months that the project has been around, they haven’t managed to even perform a literature review, let alone invent a revolutionary new technology.
One of their selling points is that unlike commercial solutions, Unblock.us is designed as a friend-to-friend system and censors cannot just built a list of IP addresses. But blocking of commercial VPNs and proxies tends to occur during political turmoil or in countries where there are no commercial interests that require access to a VPN. It probably isn’t safe to be using a proxy in such an environment anyway, but using Unblock.us is especially dangerous because (unlike Tor and commercial options) it doesn’t mix traffic from a large number of users and thus doesn’t provide any plausible deniability.
Even where it is safe to use, Unblock.us won’t impact passive DNS censorship because it will not scale. The deployment plan is identical to that of DNSChain; how many people do you know that are qualified to securely run a proxy server and willing to do it for free? You can find an unmetered VPN for less than $5/month, which is cheaper than a VPS. If someone can afford internet access, they can afford a VPN … which is easier and cheaper than paying someone to run a proxy server for you.
Unblock.us is an okay solution if you have the technical skills to operate such a proxy. However, they haven’t discovered anything revolutionary, Unblock.us’s only advantage is its relative obscurity. Since Unblock.us doesn’t provide plausible deniability, it isn’t safe for use in countries that actively block commercial proxies and VPNs. Their only realistic use case is restricted to users who have a friend that is already paying for a VPS and has the time to administer a server for free.
I didn’t want to write this blogpost, even thinking about it makes me queasy. I was sincerely hoping that Slepak would read my analysis and back-off from his claims so that I could delete the post. A few weeks ago, I even offered to write Slepak a letter of recommendation to the Shuttleworth Foundation if he would fix his marketing. After all, they funded Moxie Marlinspike to develop third party trust systems and E2E libraries. WhatsApp has adopted Marlinspike’s Signal library to provide E2E encryption for their users, but they could subvert it in a fashion similar to how websites can subvert okTurtles.
But from “MITM-proof” only applying to 1% of DNSChain users to “fixing HTTPS” for 1% of domains to claiming that Unblock.us traffic is immune from DPI … they do not care that the plain reading of their marketing doesn’t reflect the reality of their software. As Jacob Appelbaum said of Ultrasurf’s claim that it was indistinguishable from normal web traffic,
… it is super dangerous to make that claim and we would prefer to be very conservative so that when people use the system we know what they think they’re getting, honestly and truly. That is absolutely the only way we think we will be able to ethically do this kind of thing. So it’s really important if you build or work on these systems to understand that it is way better to over deliver and under promise. Because when you make a mistake or when something goes wrong, real people’s lives are really on on the line and we don’t want to mislead them.
There are other projects that are more responsible with their claims and also more advanced, such as Mailvelope, NMControl, and Tor. Instead of engaging with these communities, DNSChain and company are busy reinventing the wheel – poorly.
The Namecoin team would welcome code contributions to NMControl for a more advanced third-party trust system. It just happens to be a lower priority for us, as lightweight resolvers are generally a better solution. We want to support multiple blockchains, NMControl’s backend is pluggable and we are planning on changing NMControl’s name to be more generic. We would also love to see a NMControl plugin for the OpenName standard. As long as the security parameters are accurately conveyed, we would happily support these use cases.
Myself and others have spent a considerable amount of time trying to engage with Slepak. But I have a real job and we should be focusing on Namecoin core, NMControl, and related development efforts; as such, I do not intend to spend additional effort addressing the current marketing and technical issues surrounding okTurtles, DNSChain, or Unblock.us.
If you want to contribute to advanced censorship-resistant technology, check out Namecoin core, NMControl, and other projects listed on the Namecoin GitHub repo.
The original version of this article outlined an attack in which the service provider performed a MITM attack against the initial identity handshake. This can be fixed with out-of-band communication, but they failed to mention this and their documentation contains an image of a Twitter profile with link to a blockchain identity. I removed this attack as the UI spoofing attack is more severe and easier to explain. However, they do not prevent against all known MITM attacks and their “MITM-proof” marketing could dupe a user into thinking they don’t need to defend against this MITM attack. ↩
The exact quote used the phrase “thin clients” but it doesn’t make sense in the context of the conversation and Selpak helpfully clarified in a followup conversation on IRC that “thin clients is used as a synonym for light clients.” ↩
Their claim is that since their distribution model (“one DNSChain server per group of friends”) is a “flat” topology, there is no DNS server to DDoS. This almost makes sense if you believe that every friend group has someone willing and qualified to run a DNSChain server securely, which is about as realistic as every friend group having a friend who runs an email server for them. However, the current ISP based DNS system is very similar and we don’t see DDoS attacks against local DNS resolvers; root zone servers and nameservers are the only viable targets. Blockchains are the equivalent of the root zone server and can store DNS information within the blockchain, removing the need for a nameserver. However a DDoS attack against a cryptocurrency would also break DNSChain. ↩
DNSChain claims that “The wonderful thing about blockchains is that they have no conception of revocation because they do not need one. Instead, the most recent value for any particular key in a blockchain is the most accurate and up-to-date value.” This is based on a misunderstanding of how revocation and blockchains work. While it is possible to revoke a TLS certificate with a blockchain key, it is not possible to revoke the blockchain key. This has been pointed out to us as a security drawback by two high-profile security experts. While we intend to improve in this area (and have plans for doing so), it is incorrect to imply that the revocation problem is solved. ↩
In a response to this post, Slepak rightfully pointed out that lightweight resolvers described in the linked article are not equivalent to the full node installations, which was an oversight. There are lightweight resolvers (FN-UTXO) that offer protection just shy of a full node installation and experimental implementations required around a couple hundred megabytes. Since we are only interested in current domains, the installation size of a FN-UTXO is fairly stable, it would grow in proportion the popularity of the TLD (which can scale to the size of .info or .biz relatively easily). But in the original version of this post I started talking about FN-UTXO resolver and then immediately switched to talking about a UNO lightweight resolver, which was confusing. But, as explained in the updated version, the UNO lightweight resolver is still more secure than DNSChain’s security model.
Furthermore, Slepak’s response proves that he doesn’t understand Namecoin’s lightweight resolvers. He quoted from an O’Reilly book on Bitcoin SPV clients, stating that they had to query multiple servers, akin to DNSChain. As explained in the article I linked to originally, Namecoin’s primary lightweight resolvers (UNO resolvers) do not need to contact multiple servers. Compared to Bitcoin SPV clients, UNO resolvers do not require as much storage and offer much better security. ↩
The security model he was referring to in the original “at least as good as” quote does not specify running your own server, it only suggested that one, “Use a DNSChain server that you have reason to trust…”. ↩