Blogs

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.]

TorBirdy 0.2.2 is released

We are pleased to announce the eighth beta release of TorBirdy: TorBirdy 0.2.2. This release adds support for Thunderbird 52 and also features improved security configuration settings for Thunderbird. All users are encouraged to update.

If you are using TorBirdy for the first time, visit the wiki to get started.

There are currently no known leaks in TorBirdy but please note that we are still in beta, so the usual caveats apply.

Here is the complete changelog since v0.2.1:

0.2.2, 03 April 2017
* Bug 20751: Enforce stronger ciphers in TorBirdy
* Bug 6958, 16935, 19971: Add support for already torified keyserver
communication using modern GnuPG
* The minimum supported Thunderbird version is 45.0 and the maximum is 52.*
* Update default keyserver to OnionBalance hidden service pool

We offer two ways of installing TorBirdy: by visiting our website (GPG signature; signed by 0xB01C8B006DA77FAA) or by visiting the Mozilla Add-ons page for TorBirdy.

Please note that there may be a delay -- which can range from a few hours to days -- before the extension is reviewed by Mozilla and updated on the Add-ons page.

The TorBirdy package for Debian GNU/Linux will be uploaded shortly by Ulrike Uhlig.

Tor Messenger 0.4.0b2 is released

We are pleased to announce another public beta release of Tor Messenger. This release features important improvements to the stability and security of Tor Messenger. All users are encouraged to upgrade.

Tor Messenger 0.4.0b1 users will be automatically prompted to install the update (similar to Tor Browser). On installing and restarting, the update will be applied; your account settings and OTR keys will be preserved.

Incremental Updates

Incremental updates are disabled for this version and Tor Messenger will perform a complete update. There was a bug in the update MAR generation process that was fixed in d3834a99 but persisted across recent versions. To fix this and to ensure a smooth automatic update for future releases, we are pushing only complete updates for updating from version 0.4.0b1 to 0.4.0b2. What does this mean for you? Automatic updates will still be performed but will take a little longer.

Downloads

Please note that Tor Messenger is still in beta. The purpose of this release is to help test the application and provide feedback. At-risk users should not depend on it for their privacy and safety.

Linux (32-bit)

Linux (64-bit)

Windows

macOS

sha256sums-signed-build.txt
sha256sums-signed-build.txt.asc

The sha256sums-signed-build.txt file containing hashes of the bundles is signed with the key 0xB01C8B006DA77FAA (fingerprint: E4AC D397 5427 A5BA 8450 A1BE B01C 8B00 6DA7 7FAA). Please verify the fingerprint from the signing keys page on Tor Project's website.

Changelog

Tor Messenger 0.4.0b2 -- 31 March 2017

  • All Platforms
    • Use the tor-browser-45.8.0esr-6.5-2-build1 tag on tor-browser
    • Use the THUNDERBIRD_45_8_0_RELEASE tag on comm-esr45
    • Update tor-browser to 6.5.1
    • Trac 21634: Restore the ability to auto login, but default to off
    • Trac 17517: Consider using different color for "Add Exception"

OONI report released: The State of Internet Censorship in Thailand

SEATTLE, WA, USA – Monday, March 20th, 2017 – The Tor Project announces the release of The State of Internet Censorship in Thailand, a report from a joint research study by Open Observatory of Network Interference (OONI), Sinar Project, and the Thai Netizen Network. The study aims to increase transparency of Internet controls in Thailand and to collect data that can potentially corroborate rumors and reports of Internet censorship events. The key finding of this report reveal that Internet Service Providers (ISPs) in Thailand appear to be blocking websites at their own discretion.

"We hope the findings of this report will enhance public debate around the necessity and proportionality of information controls," said Maria Xynou, Research and Partnerships Coordinator for OONI. Adding further that "A dozen websites, including The New York Post (nypost.com), were blocked in some networks, while accessible in others, indicates that Thai ISPs are likely blocking content at their own discretion."

Multiple censorship events in Thailand have been reported over the last decade. More than 10,000 URLs were reportedly blocked by the Government in 2010. Following Thailand’s most recent coup d’etat, Citizen Lab reported that 56 websites were blocked between May and June of 2014. One importance of undertaking this study, which collects and analyzes network measurements, is to examine whether Internet censorship events are persisting in the country.

Anyone can contribute to the research efforts by OONI by installing and running ooniprobe, thus increasing the transparency of Internet censorship in Southeast Asia and beyond.

About Open Observatory of Network Interference

The Open Observatory of Network Interference (OONI) is a free software project under The Tor Project that aims to empower decentralized efforts in increasing transparency of Internet censorship around the world. Since 2012, OONI has collected millions of network measurements from more than 190 countries, shedding light on multiple instances of network interference.

About Sinar Project

Sinar Project is an initiative using open technology and applications to systematically make important information public and more accessible to the Malaysian people. It aims to improve governance and encourage greater citizen involvement in the public affairs of the nation by making the Malaysian Government more open, transparent and accountable. We build open source civic tech applications, work to open government with open data and defend digital rights for citizens to apply their democratic rights.

About Thai Netizen Network

Thai Netizen Network (TNN), founded in 2008, is a leading nonprofit organization in Thailand that advocates for digital rights and civil liberties. The group was officially registered as มูลนิธิเพื่ออินเทอร์เน็ตและวัฒนธรรมพลเมือง (Foundation for Internet and Civic Culture) in May 2014.

About Tor Project, Inc

The Tor Project develops and distributes free software and has built an open and free network that helps people defend against online surveillance that threatens personal freedom and privacy. Tor is used by human rights defenders, diplomats, government officials, and millions of ordinary people who value freedom from surveillance.

The Tor Project's Mission Statement: "To advance human rights and freedoms by creating and deploying free and open anonymity and privacy technologies, supporting their unrestricted availability and use, and furthering their scientific and popular understanding."

Media Contacts

Joshua Gay
Communications Director
Tor Project
jgay@torproject.org

Maria Xynou (OONI)
maria@openobservatory.org

Arturo Filasto (OONI)
arturo@openobservatory.org

Tor Browser 7.0a2-hardened is released

A new hardened Tor Browser release is available. It can be found in the 7.0a2-hardened distribution directory and on the download page for hardened builds.

This release features important security updates to Firefox.

This hardened alpha release mainly contains updates to several of our Tor Browser components: Firefox got updated to 45.8.0esr, Tor to 0.3.0.4-rc, OpenSSL to 1.0.2k, and HTTPS-Everywhere to 5.2.11.

Additionally, we updated the bridges we ship with Tor Browser and fixed some regressions that came with our last release.

In the previous release we introduced filtering of content requests to resource:// and chrome:// URIs in order to neuter a fingerprinting vector. This change however breaks the Session Manager addon. Users who think having extensions like that one working is much more important than avoiding the possible information leakage associated with that can now toggle the 'extensions.torbutton.resource_and_chrome_uri_fingerprinting' preference, setting it to 'true' to disable our defense against this type of fingerprinting.

Another known regression is the resizing of the window. We are currently working on a fix for this issue.

The full changelog since Tor Browser 7.0a1-hardened is:

  • All Platforms
    • Update Firefox to 45.8.0esr
    • Tor to 0.3.0.4-rc
    • OpenSSL to 1.0.2k
    • Update Torbutton to 1.9.7.1
      • Bug 21396: Allow leaking of resource/chrome URIs (off by default)
      • Bug 21574: Add link for zh manual and create manual links dynamically
      • Bug 21330: Non-usable scrollbar appears in tor browser security settings
      • Bug 21324: Don't update NoScript button with timer update
      • Translation updates
    • Update HTTPS-Everywhere to 5.2.11
    • Bug 21514: Restore W^X JIT implementation removed from ESR45
    • Bug 21536: Remove scramblesuit bridge
    • Bug 21342: Move meek-azure to the meek.azureedge.net backend and cymrubridge02 bridge
    • Bug 21326: Update the "Using a system-installed Tor" section in start script
  • Build system
    • Bug 17034: Use our built binutils and GCC for building tor
    • Code clean-up

Tor Browser 7.0a2 is released

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

This release features important security updates to Firefox.

This alpha release mainly contains updates to several of our Tor Browser components: Firefox got updated to 45.8.0esr, Tor to 0.3.0.4-rc, OpenSSL to 1.0.2k, and HTTPS-Everywhere to 5.2.11.

Additionally, we updated the bridges we ship with Tor Browser and fixed some regressions that came with our last release.

In the previous release we introduced filtering of content requests to resource:// and chrome:// URIs in order to neuter a fingerprinting vector. This change however breaks the Session Manager addon. Users who think having extensions like that one working is much more important than avoiding the possible information leakage associated with that can now toggle the 'extensions.torbutton.resource_and_chrome_uri_fingerprinting' preference, setting it to 'true' to disable our defense against this type of fingerprinting.

Another known regression is the resizing of the window. We are currently working on a fix for this issue.

The full changelog since Tor Browser 7.0a1 is:

  • All Platforms
    • Update Firefox to 45.8.0esr
    • Tor to 0.3.0.4-rc
    • OpenSSL to 1.0.2k
    • Update Torbutton to 1.9.7.1
      • Bug 21396: Allow leaking of resource/chrome URIs (off by default)
      • Bug 21574: Add link for zh manual and create manual links dynamically
      • Bug 21330: Non-usable scrollbar appears in tor browser security settings
      • Bug 21324: Don't update NoScript button with timer update
      • Translation updates
    • Update HTTPS-Everywhere to 5.2.11
    • Bug 21514: Restore W^X JIT implementation removed from ESR45
    • Bug 21536: Remove scramblesuit bridge
    • Bug 21342: Move meek-azure to the meek.azureedge.net backend and cymrubridge02 bridge
    • Bug 21348: Make snowflake only available on Linux for now
  • Linux
    • Bug 21326: Update the "Using a system-installed Tor" section in start script
  • Build system
    • OS X
      • Bug 21343: Remove unused FTE related parts for macOS
    • Linux
      • Bug 17034: Use our built binutils and GCC for building tor
      • Clean-up

Tor Browser 6.5.1 is released

Tor Browser 6.5.1 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 minor release in the 6.5 series and it mainly contains updates to several of our Tor Browser components: Firefox got updated to 45.8.0esr, Tor to 0.2.9.10, OpenSSL to 1.0.2k, and HTTPS-Everywhere to 5.2.11.

Additionally, we updated the bridges we ship with Tor Browser and fixed some regressions that came with our last release.

In Tor Browser 6.5 we introduced filtering of content requests to resource:// and chrome:// URIs in order to neuter a fingerprinting vector. This change however breaks the Session Manager addon. Users who think having extensions like that one working is much more important than avoiding the possible information leakage associated with that can now toggle the 'extensions.torbutton.resource_and_chrome_uri_fingerprinting' preference, setting it to 'true' to disable our defense against this type of fingerprinting.

An other regression introduced in Tor Browser 6.5 is the resizing of the window. We are currently working on a fix for this issue.

Here is the full changelog since 6.5:

  • All Platforms
    • Update Firefox to 45.8.0esr
    • Tor to 0.2.9.10
    • OpenSSL to 1.0.2k
    • Update Torbutton to 1.9.6.14
      • Bug 21396: Allow leaking of resource/chrome URIs (off by default)
      • Bug 21574: Add link for zh manual and create manual links dynamically
      • Bug 21330: Non-usable scrollbar appears in tor browser security settings
      • Translation updates
    • Update HTTPS-Everywhere to 5.2.11
    • Bug 21514: Restore W^X JIT implementation removed from ESR45
    • Bug 21536: Remove scramblesuit bridge
    • Bug 21342: Move meek-azure to the meek.azureedge.net backend and cymrubridge02 bridge
  • Linux
    • Bug 21326: Update the "Using a system-installed Tor" section in start script

Atlas Recent Improvements

Atlas is a web application to learn about currently running Tor relays and bridges. You can search by fingerprint, nickname, country, flags and contact information and be returned information about its advertised bandwidth, uptime, exit policies and more.

I'm taking this opportunity to introduce myself. I'm Iain R. Learmonth, or just irl on IRC. I began contributing to Atlas in June last year, and I'm currently serving as the maintainer for Atlas. We have made some usability improvements to Atlas recently that we are happy to share with you today.

Thanks to the work of Raphael and anonymous contributors for their help in producing patches. We will continue to work through the open tickets, and if you have a feature you would like to see or spot something not working quite correctly, please do feel free to open a ticket for that. If you would like to contribute to fixing some of our existing tickets, we have a new guide for contributing to Atlas.

Improved Error Handling

  • Added a new message to warn users when the Onionoo backend is unavailable [#18081]
  • Added a new message for the case where Onionoo is serving outdated data [#20374]
  • No longer attempts to display AS or geolocation information when it's not available [#18989]

UX Improvements

  • Added tooltips to give descriptions of the meaning for flags [#9913]
  • Made it easy to distinguish between "alleged" and "effective" family [#20382]
  • Removed the graphs for which the data backend will never have any data [#19553]
  • Graphs that have no data, but which may have data in the future, now give a "No Data Available" message [#21430]
  • Relay and bridge fingerprints will now wrap when on smaller screens [#12685]
  • Tooltips are repositioned to avoid them being clipped off on smaller displays [#21398]

Standards Compliance

  • Now HTML 5 compliant according to the W3C Validator (including generated HTML) [#21274]
Syndicate content Syndicate content