Maintaining a browser like Tor Browser has its challenges but also its rewards. It allows us to reach faster adoption of important technologies like onion services, providing a more secure browsing experience for all Tor users. Improving the treatment of onion services on the browser side, however, comes with its own challenges both for users and service providers and it is important to reflect on those as a requirement for future growth. Thus, we feel it is time to take stock in this blog post and outline the steps we have taken over the years to improve the user experience and adoption of onion services, the challenges we faced and continue to face, and what the future might look like.
What Does This Mean And How Did We Get Here?
Onions services are self-authenticating and provide integrity and confidentiality by default. That means once you are connected to an onion service you can be sure you are talking to the one you tried to reach and your data is not manipulated or read by Man-In-The-Middle-attackers. HTTPS was introduced over 20 years ago to provide some of those properties for plain web traffic (HTTP) when communicating with a server.
Three years ago, Mozilla announced their plan for raising awareness about the insecurity of HTTP by introducing a new visual indicator and a username/password warning message for websites loaded over HTTP (instead of HTTPS). Not knowing anything about onion services, the way this was implemented on Mozilla’s side was by looking at the scheme in the URL bar: if it is only “http” then the warning kicks in. As a result, the idea of handling connections with onion services as (inherently) “secure” was proposed because these new browser security indicators directly harmed the usability of onion sites, like those hosted by SecureDrop and Riseup. At that time, extended validation (EV) TLS certificates containing .onion addresses were available for web sites that could afford them, and those web sites were already available over HTTPS, but the certificates were too costly for the general public. Domain validation (regular) TLS certificates weren’t allowed to contain .onion addresses, and that idea wasn’t being considered.
With the immediate usability problem, we found a solution that was acceptable by Mozilla for inclusion in Firefox, as well. The solution elevated connections with .onion addresses to a “potentially trustworthy origin,” and this was defined by the Web specification as an origin (web site) that the web browser “can generally trust as delivering data securely”.
As a result of handling an .onion address as a “potentially trustworthy origin”, Tor Browser then modified how it dealt with mixed content over onion service connections and “secure cookies”. Over the last two years, based on these previous changes, onion service usability has become a primary feature of Tor Browser, and the security and improved usability of onion services are the reason we can run an onion service adoption campaign like #MoreOnionsPorfavor.
Challenges
The features mentioned in the previous section meant a lot of effort for our small team of engineers and designers. Staying on track and delivering them on time has been challenging sometimes. Additionally, we did not have the resources so far to port all of them to mobile. But we keep iterating so that all Tor users are able to benefit from the enhanced security provided by onion services when browsing the web.
All those engineering efforts depend on good communication between stakeholders to be effective and lasting. That does not only mean between the different teams within Tor to get the various improvements implemented but external stakeholders as well.
Support by browser vendors is crucial, which is why we spent effort on making our changes specification-compliant and getting them upstreamed into Firefox. Mozilla is now even proactively taking the .onion use case into account which is promising for future changes. And other browser vendors have our onion services enhancements in their pipeline as well.
We neglected another stakeholder group, though: companies like Facebook, the New York Times, Guardian, BBC and others which started to run onion services in an enterprise environment. The complexities of those environments and the lack of communication in this area led to potential security issues like the one core contributor Alec Muffett recently reported. As a consequence of that we just started to reach out to enterprises we know are running onion services and provide them with help for running those onion services securely. We have a group, called “onion-advisors,” where all of those efforts are coordinated to avoid making this mistake again in the future.
What Is The Future Of Tor Browser And Onion Services?
We are going to continue supporting onion services in Tor Browser, both with and without certificates acquired by the onion service owner, and are continuing the trend of enhancing their usability as well. We hope campaigns like #MoreOnionsPorfavor will help increase awareness of onion services and adoption by small and large web sites. As part of these campaigns we will emphasize the importance of deploying onion services that are secure end-to-end so Tor Browser doesn’t make a wrong assumption about which data should be sent over HTTP onion connections. We’re also currently improving our documentation for onion service operators and making clear Tor Browser’s expectations of web sites.
The future of TLS support for onion services is very encouraging. In March of this year, the CA/Browser Forum approved an amendment to the domain validation (DV) TLS certificate baseline requirements which now allows certificate authorities (CAs) to issue certificates containing v3 .onion addresses. This means, in the not-too-distant-future, a CA like Let’s Encrypt can issue a certificate for an onion service and Tor Browser will “just work.” In addition, for onion services that do not want to rely on certificate authorities, we are exploring alternative designs like Same Origin Onion Certificate for inclusion in Tor Browser.
While getting TLS support for onion services is important, making sure onion sites without any TLS certificate continue to get a good user experience will remain one of our priorities in the foreseeable future. After all, onion services by themselves already provide the security benefits (and more) TLS is meant to give to users in most of the cases. Additionally, there remains the idea to explore that onion routing is actually the successor of TLS security-wise. We should not give up on that easily by solely jumping on the TLS + .onion train.
There are many different scenarios possible for onion service deployment and the role browsers in general and Tor Browser in particular will play in that. Our experimenting so far seems to indicate that the changes in Tor Browser have been worth it even though deploying onion services securely has not always been easy in this fast-moving area. Where we will end up we don’t know. The only thing we can say with certainty is that this part of Tor and Tor Browser is still evolving and we are continuing to push the boundaries of a secure, private, safe, and usable web for everyone. Please watch for future improvements in Tor and Tor Browser, and please deploy secure onion services.
