Blogs

Transparency, Openness, and our 2015 Financials

After completing the standard audit, our 2015 state and federal tax filings are available. We publish all of our related tax documents because we believe in transparency.

I'm sorry for the delay in posting them: we had everything ready in December, but we had a lot going on at the end of the year (if you haven't seen it yet, check out the Tor at the Heart of Internet Freedom blog post series!), and then time got away from me after the new year.

But the delay brings you something new! Linus Nordberg, one of our new board members, has gathered together a bunch of corporate documents, like the Articles of Organization from founding the organization, our Form 1023 where we applied for non-profit status, and our IRS determination letter where they confirmed it. I've put links to these documents on the same financials page.

From a development perspective, transparency doesn't just mean that we show you our source code (though of course we do). The second layer to transparency is publishing specifications to explain what we thought we implemented in the source code. And the layer above that is publishing design documents and research papers to explain why we chose to build it that way, including analyzing the security implications and the tradeoffs of alternate designs. The reason for all these layers is to help people evaluate every level of our system: whether we chose the right design, whether we turned that design into a concrete plan that will keep people safe, and whether we correctly implemented this plan. Tor gets a huge amount of analysis and attention from professors and university research groups down to individual programmers around the world, and this consistent peer review is one of our core strengths over the past decade.

Some observations to help you read through the 2015 financial documents:

  • Tor's annual revenue in 2015 was up from 2014, at almost $3.3 million. That's good news because it shows our stability in the year where I was interim executive director. At the same time, you should be careful reading too much into yearly (calendar) numbers, because they can vary quite a bit if, say, we finish a big milestone on Dec 15 vs on Jan 15. So you really want to look at many years at a time—and by that metric, we're doing ok.
  • Tor's budget remains modest considering the number of people involved and the impact we have. And it is dwarfed by the budgets that our adversaries are spending to make the world a more dangerous and less free place.
  • Income from individual donations and other non-government things is higher, and also a higher percentage, in 2015 than 2014, but it's still in the 10-15% range. We have more work to do.
  • Check out the comment sections on the previous posts for previous years' versions of the usual "omg government funding" and "omg transparency" discussions. You might find this comment more useful than the rest.
  • A brief crash course on two common contract models for organizations that take government funding: Some of our funding (NSF, State Dept) is what's called the "cost reimbursement" model, where we have to show that we've spent the money in order to get paid (which is designed to make sure organizations spend the money in the way they've agreed to spend it), whereas others of our funding (RFA/OTF, SRI) is what's called the "milestone based" model, where we give the funder a set of deliverables and prices, and when we tell them a deliverable is done, they pay us that amount. The milestone based model gives us more flexibility to do all the things that need to get done (e.g. we can choose prices that accurately reflect the maintenance costs too), but it can also be more risky because it's on us if we underestimate costs.
  • More generally, I should take a brief moment to explain how funding proposals work, for those who worry that governments come to us wanting to pay us to do something bad. The way it works is that we try to find groups with funding for the general area that we want to work on, and then we go to them with a specific plan for what we'd like to do and how much it will cost, and if we're lucky they say ok. There is never any point where somebody comes to us and says "I'll pay you $X to do Y."
  • In 2015 we counted $498000 in "donated services", that is, volunteers helping with translations, website hosting, and so on. So far we have been quite limited in what donated services we count, because our past accounting people told us to be conservative. Other people have told us that we don't have to be that conservative, so I am excited to try harder in future financial documents to count many more aspects of volunteering—activism and education, sysadmin time, relay operation, finding and analyzing bugs, providing user support, etc.

In closing, remember that there are many different ways to get involved with Tor, and we need your help. For examples, you can donate, volunteer, and run a Tor relay.

Discontinuing the hardened Tor Browser series

When we started with the hardened Tor Browser series 18 months ago, we had two main purposes in mind:

  • It should give users an even more secure Tor Browser, especially at higher security levels where JavaScript is partially or completely disabled.
  • It should help us to identify issues earlier, therefore allowing to develop and backport fixes to the Tor Browser alpha and stable series.

The hardened series was a non-stable series on purpose, aimed at experienced users. The reason for that was not only the heavy performance impact of the hardening and debugging features we deployed. Rather, the impact of mixing both in Tor Browser seemed to be not well understood either: for example, does compiling Tor Browser with Address Sanitizer really lead to a more secure browser, given that the sanitizer is mainly intended as a debugging tool? Moreover, just using the hardening options provided by the toolchain seemed to be an incomplete solution to the problem—a bandaid until we could provide a more complete approach to hardening.

Looking again at its purposes above, we think it is safe to say that the hardened series indeed helped us identifying issues early on: with it we found bugs both in Firefox and tor and they got resolved quickly.

The picture is not so clear with respect to the promised security benefits. Part of the problem is that "more secure" can mean a wide variety of things. Another part is that we did not measure if we were indeed adding a security benefit to Tor Browser with all the techniques we deployed. What we learned over the course of the past 18 months, however, is that enabling expensive hardening can aid in making Tor Browser crashes much more reliable.

But that's not the only thing we learned. It seems we underestimated the confusion among users caused by labeling the series as "hardened" while at the same time including features for debugging purposes as well. The resulting experimental character of this series made it hard for users to decide whether that's actually the Tor Browser they wanted to have or not.

Where does that leave us? We've decided to stop having a "hardened" browser series, and instead we'll provide separate tools for the two purposes that it aimed to solve:

Users that are currently on the hardened update channel will get an update to the most recent Tor Browser alpha with a note to use Sandboxed Tor Browser instead for enhanced security. While the Sandboxed Tor Browser is currently in an experimental state itself, we feel that it provides much better safeguards against exploitation than the features we shipped in the hardened series.

Having Sandboxed Tor Browser for hardening the browser experience allows us to do an even better job with finding problems earlier in our Tor Browser patches or code in Tor Browser generally: we can include more debugging aids into special debug builds. We plan to do so and get back to dedicated debug nightly builds when we switch to our reproducible builds manager (rbm), which is happening soon.

Finally, thanks to all users of the hardened Tor Browser series. We hope Sandboxed Tor Browser and the upcoming debug builds will provide an even better match to your needs. If not, please make sure to file a bug in our bug tracker and we'll look into it.

Tor Browser 7.0a3 is released

Tor Browser 7.0a3 is now available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox.

This is the first alpha release which is based on Firefox ESR 52. We updated all of our patches that did not get upstreamed yet and made Torbutton and Tor Launcher multiprocess (e10s) compatible. After the first nightly build based on ESR52 went out we already fixed a number of bugs associated with this switch. But more remain, please help!

We hope having e10s and Mozilla's content sandbox enabled will be one of the major new features in the upcoming Tor Browser 7.0 series, both security- and performance-wise. While we are still working on the sandboxing part for Windows, both Linux and macOS have e10s and content sandboxing enabled by default in Tor Browser 7.0a3. There are already a number of bugs related to that on our radar which can be found on our bug tracker and which are tagged with the `tbb-e10s` keyword. If you find more, please report them!

The switch to Firefox ESR 52 raises the system requirements for Tor Browser on Windows and macOS. Computers running Windows and are not SSE2-capable are not supported anymore. On Apple computers with OS X < 10.9 Tor Browser won't run anymore either.

We updated our toolchains during the ESR transition as well. In particular we retired the old GCC-based one for our macOS cross-compilation and rely solely on clang/cctools now. As with previous releases building 7.0a3 is fully reproducible on all three supported platforms, even though we needed to deploy a last minute patch for Linux bundles this time.

Apart from switching to the new ESR and dealing with related issues we included a new Tor alpha (0.3.0.5-rc) and updated our NoScript (5.0.2) and HTTPS-Everywhere versions (5.2.14). The Sandboxed Tor Browser for Linux got updated to 0.0.6 making sure it is compatible with Firefox ESR 52.

As in Tor Browser 6.5.2 we provide a fix for Tor Browser crashing on github.com on Windows and for Twitter issues that got reported already a while ago. We update our security slider as well taking newer JIT preferences into account.

A note to Windows users: We signed the .exe files with a new codesigning certificate as the old one is about to expire. If there are issues with that new certificate, e.g. scary warnings showing up after downloading a Tor Browser .exe file and double-clicking on it, please let us know.

The full changelog since Tor Browser 7.0a2 is:

  • All Platforms
    • Update Firefox to 52.1.0esr
    • Tor to 0.3.0.5-rc
    • Update Torbutton to 1.9.7.2
      • Bug 21865: Update our JIT preferences in the security slider
      • Bug 21747: Make 'New Tor Circuit for this Site' work in ESR52
      • Bug 21745: Fix handling of catch-all circuit
      • Bug 21547: Fix circuit display under e10s
      • Bug 21268: e10s compatibility for New Identity
      • Bug 21267: Remove window resize implementation for now
      • Bug 21201: Make Torbutton multiprocess compatible
      • Translations update
    • Update Tor Launcher to 0.2.12
      • Bug 21920: Don't show locale selection dialog
      • Bug 21546: Mark Tor Launcher as multiprocess compatible
      • Bug 21264: Add a README file
      • Translations update
    • Update HTTPS-Everywhere to 5.2.14
    • Update NoScript to 5.0.2
    • Update sandboxed-tor-browser to 0.0.6
      • Bug 21764: Use bubblewrap's `--die-with-parent` when supported
      • Fix e10s Web Content crash on systems with grsec kernels
      • Bug 21928: Force a reinstall if an existing hardened bundle is present
      • Bug 21929: Remove hardened/ASAN related code
      • Bug 21927: Remove the ability to install/update the hardened bundle
      • Bug 21244: Update the MAR signing key for 7.0
      • Bug 21536: Remove asn's scramblesuit bridge from Tor Browser
      • Add back old MAR signing key to not break updating Tor Browser stable
      • Add `prlimit64` to the firefox system call whitelist
      • Fix compilation with Go 1.8
      • Use Config.Clone() to clone TLS configs when available
    • Update Go to 1.7.5 (bug 21709)
    • Bug 21555+16450: Don't remove Authorization header on subdomains (e.g. Twitter)
    • Bug 21887: Fix broken error pages on higher security levels
    • Bug 21876: Enable e10s by default on all supported platforms
    • Bug 21876: Always use esr policies for e10s
    • Bug 20905: Fix resizing issues after moving to a direct Firefox patch
    • Bug 21875: Modal dialogs are maximized in ESR52 nightly builds
    • Bug 21885: SVG is not disabled in Tor Browser based on ESR52
    • Bug 17334: Hide Referer when leaving a .onion domain (improved patch)
    • Bug 3246: Double-key cookies
    • Bug 8842: Fix XML parsing error
    • Bug 16886: 16886: "Add-on compatibility check dialog" contains Firefox logo
    • Bug 19192: Untrust Blue Coat CA
    • Bug 19955: Avoid confusing warning that favicon load request got cancelled
    • Bug 20005: Backport fixes for memory leaks investigation
    • Bug 20755: ltn.com.tw is broken in Tor Browser
    • Bug 21896: Commenting on website is broken due to CAPTCHA not being displayed
    • Bug 20680: Rebase Tor Browser patches to 52 ESR
    • Bug 21917: Add new obfs4 bridges
    • Bug 21918: Move meek-amazon to d2cly7j4zqgua7.cloudfront.net backend
  • Windows
    • Bug 21795: Fix Tor Browser crashing on github.com
    • Bug 12426: Make use of HeapEnableTerminationOnCorruption
    • Bug 19316: Make sure our Windows updates can deal with the SSE2 requirement
    • Bug 21868: Fix build bustage with FIREFOX_52_0_2esr_RELEASE for Windows
  • OS X
    • Bug 21723: Fix inconsistent generation of MOZ_MACBUNDLE_ID
    • Bug 21724: Make Firefox and Tor Browser distinct macOS apps
    • Bug 21931: Backport OSX SetupMacCommandLine updater fixes
    • Bug 15910: Don't download GMPs via the local fallback
  • Linux
    • Bug 21907: Fix runtime error on CentOS 6
    • Bug 21748: Fix broken Snowflake build and update bridge details
    • Bug 21954: Snowflake breaks the 7.0a3 build
    • Bug 15910: Don't download GMPs via the local fallback
  • Build system
    • Windows
      • Bug 21837: Fix reproducibility of accessibility code for Windows
      • Bug 21240: Create patches to fix mingw-w64 compilation of Firefox ESR 52
      • Bug 21904: Bump mingw-w64 commit to help with sandbox compilation
      • Bug 18831: Use own Yasm for Firefox cross-compilation
    • OS X
      • Bug 21328: Updating to clang 3.8.0
      • Bug 21754: Remove old GCC toolchain and macOS SDK
      • Bug 19783: Remove unused macOS helper scripts
      • Bug 10369: Don't use old GCC toolchain anymore for utils
      • Bug 21753: Replace our old GCC toolchain in PT descriptor
      • Bug 18530: ESR52 based Tor Browser only runs on macOS 10.9+
    • Linux
      • Bug 21930: NSS libraries are missing from mar-tools archive
      • Bug 21239: Adapt Linux Firefox descriptor to ESR52 (use GTK2)
      • Bug 21960: Linux bundles based on ESR 52 are not reproducible anymore
      • Bug 21629: Fix broken ASan builds when switching to ESR 52

Tor Browser 6.5.2 is released

Tor Browser 6.5.2 is now available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox.

This should be the last minor release in the 6.5 series. This release updates Firefox to 45.9.0esr, Noscript to 5.0.2, and HTTPS-Everywhere to 5.2.14.

Moreover, we included a fix for the broken Twitter experience and worked around a Windows related crash bug. To improve our censorship resistance we additionally updated the bridges we ship.

Here is the full changelog since 6.5.1:

  • All Platforms
    • Update Firefox to 45.9.0esr
    • Update HTTPS-Everywhere to 5.2.14
    • Update NoScript to 5.0.2
    • Bug 21555+16450: Don't remove Authorization header on subdomains (e.g. Twitter)
    • Bug 19316: Make sure our Windows updates can deal with the SSE2 requirement
    • Bug 21917: Add new obfs4 bridges
    • Bug 21918: Move meek-amazon to d2cly7j4zqgua7.cloudfront.net backend
  • Windows
    • Bug 21795: Fix Tor Browser crashing on github.com

Tails 2.12 is out

This release fixes many security issues and users should upgrade as soon as possible.

New features

  • We installed again GNOME Sound Recorder to provide a very simple application for recording sound in addition to the more complex Audacity. Sound clips recorded using GNOME Sound Recorder are saved to the Recordings folder.

Upgrades and changes

  • We removed I2P, an alternative anonymity network, because we unfortunately have failed to find a developer to maintain I2P in Tails. Maintaining software like I2P well-integrated in Tails takes time and effort and our team is too busy with other priorities.

  • Upgrade Linux to 4.9.13. This should improve the support for newer hardware (graphics, Wi-Fi, etc.).

For more details, read our changelog.

Known issues

None specific to this release.

See the list of long-standing issues.

Get Tails 2.12

What's coming up?

Tails 3.0 is scheduled for June 13th.

Have a look at our roadmap to see where we are heading to.

We need your help and there are many ways to contribute to Tails (donating is only one of them). Come talk to us!

Support and feedback

For support and feedback, visit the Support section on the Tails website.

Statement regarding Dmitry Bogatov

The Tor Project has been following with interest the case of Dmitry Bogatov in Russia, but we have no insight or information other than what we've been reading on publicly available websites.

The Tor Project does not collect any information or data that can be used to identify users of the Tor network. We do collect and publish information about Tor exit nodes and relays when relay operators voluntarily choose to send such information to the Tor Project servers. Data about individual Tor relays and the Tor network can be explored through the following sites:

  • Metrics Portal provides analytics for the Tor network, including graphs of its available bandwidth and estimated userbase;
  • Atlas is a web application to learn about currently running Tor relays; and
  • ExoneraTor answers the question of whether there was a Tor relay running on a given IP address on a given date.

What we know right now is that serious accusations of wrongdoing have been made against a valued member of our community, a person who has, among other things, been a Tor relay operator, Debian Developer, GNU developer, and privacy activist. We are collecting facts, monitoring the situation closely, and sharing information with allied organizations and individuals.

Tor 0.3.0.5-rc is released: almost stable!

Tor 0.3.0.5-rc fixes a few remaining bugs, large and small, in the 0.3.0 release series.

This is the second release candidate in the Tor 0.3.0 series, and has much fewer changes than the first. If we find no new bugs or regressions here, the first stable 0.3.0 release will be nearly identical to it.

You can download the source code from the usual place on the website, but most users should wait for packages to become available over the upcoming weeks. There should be a new Tor Browser alpha release containing Tor 0.3.0.5-rc some time later this month.

Please note: This is a release candidate, but not a stable release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.

Changes in version 0.3.0.5-rc - 2017-04-05

  • Major bugfixes (crash, directory connections):
    • Fix a rare crash when sending a begin cell on a circuit whose linked directory connection had already been closed. Fixes bug 21576; bugfix on 0.2.9.3-alpha. Reported by Alec Muffett.
  • Major bugfixes (guard selection):
    • Fix a guard selection bug where Tor would refuse to bootstrap in some cases if the user swapped a bridge for another bridge in their configuration file. Fixes bug 21771; bugfix on 0.3.0.1-alpha. Reported by "torvlnt33r".

  read more »

Cooking With Onions: Names for your onions





Hello again,

this blog post is the second issue of the Cooking with Onions series which aims to highlight interesting aspects of the onion space. Check-out our first issue as well!

Onion addresses are weird...

This post is about onion addresses being weird and the approaches that can be taken to improve onion service usability.

In particular, if you've cruised around the onionspace, you must have noticed that onion services typically have random-looking addresses that look like these:

  • 3g2upl4pq6kufc4m.onion
  • 33y6fjyhs3phzfjj.onion
  • propub3r6espa33w.onion

So for example, if you wanted to visit the Tor website onion service, you would have to use the address http://expyuzz4wqqyqhjn.onion/ instead of the usual https://www.torproject.org.

To better understand why onion addresses are so strange, it helps to remember that onion services don't use the insecure Domain Name System (DNS), which means there is no organization like ICANN to oversee a single root registry of onion addresses or to handle ownership dispute resolution of onion addresses. Instead, onion services get strong authentication from using self-authenticating addresses: the address itself is a cryptographic proof of the identity of the onion service. When a client visits an onion service, Tor verifies its identity by using the address as ground truth.

In other words, onion services have such absurd names because of all the cryptography that's used to protect them. Cryptographic material are basically huge numbers that look meaningless to most humans, and that's the reason onion addresses tend to look random as well.

To motivate this subject further, Tor developers have medium-term future plans for upgrading the cryptography of onion services, which has the side-effect of increasing onion address length to 54 characters! This means that in the future onion addresses will look like this:

  • llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymlead.onion
  • lfels7g3rbceenuuqmpsz45z3lswakqf56n5i3bvqhc22d5rrszzwd.onion
  • odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion

Remembering onions

Over the years the Tor community has come up with various ways of handling these large and non-human-memorable onion addresses. Some people memorize them entirely or scribe them into secret notebooks, others use tattoos, third-party centralized directories or just google them everytime. We've heard of people using decks of cards to remember their favorite onion sites, and others who memorize them using the position of stars and the moon.

We believe that the UX problem of onion addresses is not actually solved with the above ad-hoc solutions and remains a critical usability barrier that prevents onion services from being used by a wider audience.

The onion world never had a system like DNS. Even though we are well aware that DNS is far from the perfect solution, it's clear that human memorable domain names play a fundamental role in the user experience of the Internet.

In this blog post we present you a few techniques that we have devised to improve the usability of onion addresses. All of these ideas are experimental and come with various fun open questions, so we are still in exploration mode. We appreciate any help in prototyping, analyzing and finding flaws in these ideas.






Idea 1) A modular name system API for Tor onion services


During the past years, many research groups have experimented and designed various secure name systems (e.g. GNS, Namecoin, Blockstack). Each of these systems has its own strengths and weaknesses, as well as different user models and total user experience. We are not sure which one works best for the onion space, so ideally we'd like to try them all and let the community and the sands of time decide for us. We believe that by integrating these experimental systems into Tor, we can greatly strengthen and improve the whole scientific field by exposing name systems to the real world and an active and demanding userbase.

For this reason and based on our experience with modular anti-censorship techniques, we designed a generic & modular scheme through which any name system can be integrated to Tor: Proposal 279 defines A Name System API for Tor Onion Services which can be used to integrate any complex name system (e.g. Namecoin) or even simple silly naming schemes (e.g. a local /etc/tor-hosts file).

Here is a graphical depiction of the Name System API with a Namecoin module enabled and resolving the domain sailing.tor for a user:


It's worth pointing out that proposal 279 is in draft status and we still need to incorporate feedback received in the mailing list. Furthermore, people have pointed out simple ways through which we can fast-track and prototype the proposal faster. Help in implementing this proposal is greatly appreciated (find us in IRC!).


Idea 2) Using browser extensions to improve usability


Other approaches for improving the usability of onion addresses use the Tor Browser as a framework: think of browser extensions that map human memorable names to onion addresses.

There are many variants here so let's walk through them:

Idea 2.1) Browser Extension + New pseudo-tld + Local onion registry


A browser extension like HTTPS-everywhere, uses an onion registry to map human-memorable addresses from a new pseudo-tld (e.g. ".tor") to onion addresses. For example, it maps "watchtower.tor" to "fixurqfuekpsiqaf.onion" and "globaleconomy.tor" to "froqh6bdgoda6yiz.onion". Such an onion registry could be local (like HTTPS-everywhere) or remote (e.g. a trusted append-only database).

Even an extension with a local onion registry would be a very effective improvement to the current situation since it would be pretty usable and its security model is easy to understand: an audited local database seems to work well for HTTPS-everywhere. However, there are social issues here: how would the onion registry be operated and how should name registrations be handled? I can see people fighting for who will get bitcoin.tor first. That said, this idea can be beneficial even with a small onion database (e.g. 50 popular domains).

Here is a graphical depiction of a browser extension with a local onion registry resolving the domain sailing.tor for a user:





Idea 2.2) Browser extension + New pseudo-tld + Remote onion registries


A more dynamic alternative here involves multiple trusted remote onion registries that the user can add to their torrc. Imagine a web-of-trust based system where you add your friend's Alice onion registry and then you can visit facebook using facebook.alice.onion.

A similar more decentralized alternative could be a browser addon that uses multiple remote onion registries/notaries to resolve a name, employing a majority or supermajority rule to decide the resolution results. Such a system could involve notary nodes similar to SSL schemes like Convergence.


Idea 2.3) Browser extension redirects existing DNS names


An easier but less effective approach would be for the browser extension to only map DNS domain names to onion names. So for example, it would map "duckduckgo.com" to "3g2upl4pq6kufc4m.onion". That makes the job of the name registrar easier, but it also heavily restricts users only to services with a registered DNS domain name. Some attempts have already been made in this area but unfortunately they never really took off.


Idea 2.4) Automatic Redirection using HTTP


The Alt-Svc HTTP header defines a way for a website to say "I'm facebook.com but you should talk to me using fbcdn.com." If we replace that fbcdn.com address with facebookcorewwi.onion - then when you typed in Facebook, the browser would, under the covers, use the .onion address. And this can be done without any browser extension whatsoever.

One problem is that the browser has to remember this mapping, and in Tor Browser that mapping could be used to track or correlate you. Preloading the mapping would solve this, but how to preload the mapping probably brings us back into the realm of a browser extension.


Idea 2.5) Smart browser bookmarks for onion addresses


Talking about random addresses, it's funny how people seem to be pretty happy handling phone numbers (big meaningless random numbers) using a phone book and contacts on their devices.

On the same note, an easier but less usable approach would be to enhance Tor Browser with some sort of smart bookmark/petname system which allows users to register custom names for onion sites, and allows them to trust them or share them with friends. Unfortunately, it' unclear whether the user experience of this feature would make it useful to anyone but power users.

Of course it's important to realize that any approach that relies on a browser extension will only work for the web, and you wouldn't be able to use it for arbitrary TCP services (e.g. visiting an IRC server)


Idea 3) Embed onion addresses in SSL certificates


So let's shift back to non-browser approaches!

Let's Encrypt is an innovative project which issues free SSL certificates in an automated fashion. It has greatly improved Internet security since now anyone can freely acquire an SSL certificate for their service and provide link security to their users.

Now let's imagine that Let's Encrypt embedded onion address information into the certificates it issues, for clients with both a normal service and an onion service. For example, the onion address could be embedded into a custom certificate extension or in the C/ST/L/O fields. Then Tor Browser, when visiting such an SSL-enabled website, would parse and validate the certificate and if an onion address is included, the browser would automagically redirect the user. Take a look at this paper for some more neat ideas on this area.


Idea 4) Embed onion addresses in DNS/DNSSEC records


A similar approach could use the DNS system instead of the SSL CA system. For example, site owners could add their onion address into their TXT or SRV DNS records and Tor could learn to redirect users to the onion address. Of course this approach only applies to operators that can afford a DNS domain. Oh yeah DNS also has zero security...

Conclusion

As you can see there are many approaches that we should explore to improve usability in this area. Each of them comes with its own tradeoffs and applies to different users, so it's important that we allow users to experiment with various systems and let each community decide which approach works best for them.

It's also worth pointing out that some of these approaches are not that hard to implement technically, but they still require lots of effort and community building to really take off and become effective. Involving and pairing with other friendly Internet privacy organizations is essential to achieve our goals.

Furthermore, we should think carefully of unintended usability and security consequences that come with using these systems. For example, people are not used to their browser automagically redirecting them from one domain to another: this can seriously freak people out. It's also not clear how Tor Browser should handle these special names to avoid SSL certificate verification issues and hostname leaks.

One thing is for sure: even though onion services are used daily by thousand of people, the random addresses confuse casual users and prevent the ecosystem from maturing and achieving widespread adoption. We hope that this blog post inspires researchers and developers to toy around with naming systems and take the initiative in building and experimenting with the various approaches. Please join the [tor-dev] mailing list and share your thoughts and projects with us!




And this brings us to the end of this post. Hope you enjoyed this issue of Cooking With Onions! We will be back soon, always with the finest produce and the greatest cooking tips! What would you like us to cook next?

[Thanks to Philipp Winter and Tom Ritter for the feedback on this blog post, as well as to everyone who has discussed and helped develop these ideas.]

Syndicate content Syndicate content