tor-dev December 2017

tor-dev@lists.torproject.org

31 participants
30 discussions

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
by George Kadianakis 26 Oct '18

26 Oct '18

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header ======================================================================== 1. Motivation: Lots of high-profile websites have onion addresses these days (e.g. Tor , NYT, blockchain, ProPublica). All those websites seem confused on what's the right way to inform their users about their onion addresses. Here are some confusion examples: a) torproject.org does not even advertise their onion address to Tor users (!!!) b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion address and completely wrecking the UX (loses URL params, etc.) c) ProPublica has a "Browse via Tor" section which redirects to the onion site. Ideally there would be a consistent way for websites to inform their users about their onion counterpart. This would provide the following positives: + Tor users would use onions more often. That's important for user education and user perception, and also to partially dispell the darkweb myth. + Website operators wouldn't have to come up with ad-hoc ways to advertise their onion services, which sometimes results in complete breakage of the user experience (particularly with blockchain) This proposal specifies a simple way forward here that's far from perfect, but can still provide benefits and also improve user-education around onions so that in the future we could employ more advanced techniques. Also see Tor ticket #21952 for more discussion on this: https://trac.torproject.org/projects/tor/ticket/21952 2. Proposal Websites use the Alt-Svc HTTP header to specify their onion counterpart: http://httpwg.org/http-extensions/alt-svc.html The Tor Browser intercepts that header (if any) and auto-redirects the user to the onion site. Tor Browser only does so if the header is served over HTTPS. (That's it.) 3. Improvements 3.1. User education through notifications To minimize the probability of users freaking out about auto-redirects Tor Browser could inform the user that the auto-redirect is happening. This could happen with a small notification bar [*] below the URL bar informing users that "Tor Browser is auto-redirecting you to the secure onion site". The notification bar could also have a question mark button that provides the user with additional information on the merits of onion sites and why they should like them. [*]: like this one: http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg 3.2. Auto-redirects too intrusive? Make them optional. If we think that auto redirects are too intrusive, we should consider making them optional, or letting the website specify the desired behavior. If a website wants to specify an onion address but doesn't like auto-redirects, it could specify that as part of Alt-Svc and we could still inform the user that an onion is available using a notification bar again. 4. Drawbacks This proposal is far from the perfect solution of course. Here are a few reasons why: 4.1. Auto-redirects are scary Novice users or paranoid users might freak out with auto-redirects since it's unexpected. They might think they are under attack or they got hacked. An argument against that is that we are already using HTTPS-everywhere which is basically a redirection layer, and while its redirection technique is simpler, sometimes the derivative URL is not similar to the original URL, and we still don't see people freaking out. I think that's because people trust Tor Browser to do the right thing. Combining this knowledge with section 3.1 might solve this problem. 4.2. No security/performance benefits While we could come up with auto-redirect proposals that provide security and performance benefits, this proposal does not actually provide any of those. As a matter of fact, the security remains the same as connecting to normal websites (since we trust its HTTP headers), and the performance gets worse since we first need to connect to the website, get its headers, and then also connect to the onion. Still _all_ the website approaches mentioned in the "Motivation" section suffer from the above drawbacks, and sysadmins still come up with ad-hoc ways to inform users abou their onions. So this simple proposal will still help those websites and also pave the way forward for future auto-redirect techniques. 4.3. Alt-Svc does not do exactly what we want I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL in the location bar, document.location or any other indication of where the resource is; this is a “layer below” the URL.". IIUC, this is not exactly what we want because users will not notice the onion address, they will not get the user education part of the proposal and their connection will still be slowed down. I think we could perhaps change this in Tor Browser so that it rewrites the onion address to make it clear to people that they are now surfing the onionspace. [*]: https://www.mnot.net/blog/2016/03/09/alt-svc 5. The future As I said this is just a simple proposal to introduce the auto-redirect concept to people, and also to help some sysadmins who are currently coming up with weird ways to inform people about their onions. It's not the best way to do this, but it's definitely one of the simplest ways. In the future we could implement with more advanced auto-redirect proposals like: a) Have a "domains to onions" map into HTTPS-everywhere and have it do the autoredirects for us (performance benefits, and security benefits under many threat models). b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested by comment:42 in #21952. But both of the designs above require non-trivial engineering/policy work and would still confuse people. So I think starting with a simple approach that will educate users and then moving to more advanced designs is a more normative way to go. ====================================================================== Let me know what you think :) (Should this be part of torspec?)

10 25

Proposal: Expose raw bwauth votes
by Tom Ritter 16 Jul '18

16 Jul '18

I'm not sure, but I think https://trac.torproject.org/projects/tor/ticket/21377 needed a proposal so I tried to write one up. -tom

5 8

Nominate/vote for future proposal discussion meetings!
by isis agora lovecruft 21 Feb '18

21 Feb '18

Hello all, Is there an existing Tor proposal you'd like to discuss? Please use the following pad to nominate and vote for proposals for discussion. https://pad.riseup.net/p/Pxo2fQiiaSWo We'll be reviving our proposal discussion meetings soon, likely at the beginning of January once people have returned from their winter holidays. After the nominations/votes are taken, I'll start arranging meeting times. If you nominate and/or vote for a proposal, I may reach out to you at some point for your opinions on discussion items, open questions/concerns, etc. to include for the meeting preparation. Thanks! Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

6 18

non-anonymous ephemeral onion services with stem
by Micah Lee 30 Jan '18

30 Jan '18

The stem documentation for create_ephemeral_hidden_service [1] says: "Changed in version 1.5.0: Added support for non-anonymous services." But I can't figure out to actually use this feature. There doesn't seem to be a new argument to say if you want your onion service to be non-anonymous. It also says, "Changed in version 1.5.0: Added the basic_auth argument." But there's a new basic_auth argument you can pass into the function to use that. [1] https://stem.torproject.org/api/control.html#stem.control.Controller.create…

5 12

Error-Correcting Onions with Bech32
by nullius 12 Jan '18

12 Jan '18

# Synopsis The Bech32 standard for error-correcting base32 strings was developed explicitly for relative ease and reliability in human communication of pseudorandom bitstrings. I invite discussion of specifying Bech32 as an alternative means for representing RFC 7686 .onion domain names. Should the response hereto be positive, then I will offer a formal proposal. I have written and released a tool which automatically recognizes and encodes/decodes .onion addresses in Bech32. To complement whatever I here say, please get a hands-on feel for Bech32 .onions: https://github.com/nym-zone/bech32 Manpage (yes, a real manpage!): https://raw.githubusercontent.com/nym-zone/bech32/master/bech32.1.txt # Background: About Bech32 Bech32 is specified by the Bitcoin BIP 173 standard,[1] co-authored by Pieter Wuille and Greg Maxwell. According to Mr. Maxwell, “Bech32 is designed for human use and basically nothing else”; the underlying research and development process involved extensive testing with human users, analysis of NIST visual confusability data, and the integration of a BCH code with strong error correction and detection properties. [1] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki I refer to BIP 173 for further explanation of Bech32’s design properties, its rationales, and the limits of its error handling. A specific application of Bech32 is Bitcoin’s new address format for the future, which I call “Bravo Charlie Addresses” after the letters “bc” specified for Bitcoin addresses in the standard’s “human-readable part” (HRP). However, the standard was written to permit general use in other applications. Having in hand a standard explicitly designed to ease the pain which wetware suffers when it comes into contact with pseudorandom gibberish, the cypherpunk in me is overjoyed at the potentials. One is a concept which I call “PGP Descriptors”, which I am currently working to specify with a few extra features and nuances. And of course, I think of .onions! # Bech32 for .onion I hereby nominate “onion” as the logical HRP for RFC 7686 .onion special-use domain names. Here is Bech32 .onion by example, using my bech32 tool with its built-in .onion support to encode and decode the name for the Tor Project’s .onion equivalent of its “www” site: ``` $ bech32 -e expyuzz4wqqyqhjn.onion onion1yh0c5eeuksscs8fdyd8406 $ bech32 -d onion1yh0c5eeuksscs8fdyd8406 expyuzz4wqqyqhjn.onion ``` The string is longer, because it contains 6 base32 characters’ worth of error-correcting code. N.b. also, the foregoing should work just fine for v3 onions (formerly prop-224). Imagine the impact on users who have a practical need to transmit a .onion address by verbal communication, or via a handwritten note. Now they can get some help with errors, instead of wondering why they can’t connect to a nonexistent .onion site. The standard enjoins applications against autocorrecting Bitcoin addresses, so as to prevent even the slightest possibility of causing funds loss by being too “helpful”. But in applications where it would be safe to do so, Bech32 can indeed correct small errors (as well as reliably detecting much worse errors). I suggest that such automatic correction would be suitable for .onion addresses. Bech32 co-author Dr. Wuille (sipa) has published Javascript reference code, plus a Javascript error-correction demo, under an MIT license. Perhaps this may be easily adapted into Torbutton, for automagic decoding of Bech32 “onion1” to .onion domains in the Tor Browser address bar. The code is in the same repository whence I copied the Bech32 reference C code I use internally in my tool: https://github.com/sipa/bech32 # Conclusion—or, to be continued... An alternative representational format with error-correcting codes will make .onion addresses more human-friendly. I look forward to the day when “onion1” addresses can be passed by handwritten notes, vocalized with a radio alphabet, stuffed into QR codes, scrawled on parchments placed in bottles tossed to sea, rocketed into space, and then conveniently transformed with appropriate corrections into the DNS-style .onion format specified by RFC 7686. Here’s to the alternative Onion format of the future! -- nullius(a)nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) “‘If you’re not doing anything wrong, you have nothing to hide.’ No! Because I do nothing wrong, I have nothing to show.” — nullius

6 15

New Fallback Directory File Format
by teor 12 Jan '18

12 Jan '18

Hi all, Some time in the next few weeks, the Tor fallback directory mirror file format will change. This affects stem and Relay Search, which parse this file. Change Description Here is a list of changes to the file format: * the "weight" line has been removed, and replaced with a Tor config default (#24679, #24681) * the comma that separates fallback C strings is now on its own line * a "nickname" comment has been added (#24600) * an optional "extrainfo" comment has been added (#22759) The added fields will be populated with placeholders until the list is rebuilt (#22271). This will hopefully happen some time in the next few weeks. Requesting More Extra Info Caches There are only a few fallbacks that cache extra-info documents. I checked 67, and only 4 cached extra-info documents. atagar, do you want me to ask some fallback operators to set DownloadExtraInfo 1? What number or proportion would you like? (We allow approximately 25% of fallbacks to go down before we start to rebuild the list. In the worst case, this can mean that ~40% are down at some point.) Example Entries A sample entry in the new format, using actual relay info: "5.9.110.236:9030 orport=9001 id=0756B7CD4DFC8182BE23143FAC0642F515182CEB" " ipv6=[2a01:4f8:162:51e2::2]:9001" /* nickname=rueckgrat */ /* extrainfo=1 */ , The current fallback file in the new format, with placeholders: https://github.com/teor2345/tor/blob/ticket22759_tree/src/or/fallback_dirs.… A small sample fallback file in the new format, with actual relay info: https://trac.torproject.org/projects/tor/attachment/ticket/22759/fallback_d… Please let me know if you would like any changes to the format. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

4 14

Proposal 285: Directory documents should be standardized as UTF-8
by Nick Mathewson 10 Jan '18

10 Jan '18

Filename: 285-utf-8.txt Title: Directory documents should be standardized as UTF-8 Author: Nick Mathewson Created: 13 November 2017 Status: Open 1. Summary and motivation People frequently want to include non-ASCII text in their router descriptors. The Contact line is a favorite place to do this, but in principle the platform line would also be pretty logical. Unfortunately, there's no specified way to encode non-ASCII in our directory documents. Fortunately, almost everybody who does it, uses UTF-8 anyway. As we move towards Rust support in Tor, we gain another motivation for standarding on UTF-8, since Rust's native strings strongly prefer UTF-8. So, in this proposal, we describe a migration path to having all directory documents be fully UTF-8. 2. Proposal First, we should have Tor relays reject ContactInfo lines (and any other lines copied directly into router descriptors) that are not UTF-8. At the same time, we should have authorities reject any router descriptors or extrainfo documents that are not valid UTF-8. Simultaneously, we can have all Tor instances reject all non-directory-descriptor directory documents that are not UTF-8, since none should exist today. Finally, once the authorities have updated, we should have all Tor instances reject all directory documents that are not UTF-8. (We should not take this step until the authorities have upgraded, or else the behavior of updated and non-updated clients could be distinguished.) 2.1. Hidden service descriptors' encrypted bodies For the encrypted bodies of hidden service descriptors, we cannot reject them at the authority level, and so we need to take a slightly different approach to prevent client fingerprinting attacks. First, we should make Tor instances start warning about any hidden service descriptors whose bodies, post-decryption, contain non-utf-8 plaintext. At the same time, we add a consensus parameter to indicate that hidden service descriptors with non-utf-8 plantexts should be rejected entirely: "reject-encrypted-non-utf-8". If that parameter is set to 1, then hidden service clients will not only warn, but reject the descriptors. Once the vast majority of clients are running versions that support the "reject-encrypted-non-utf-8" parameter, that parameter can be set to 1.

5 6

Relay diversity master thesis
by Robin Descamps 07 Jan '18

07 Jan '18

Hello, I already sent this message to the metrics team, but they advice me to address it to the dev team, which seem to be more relevant. I realise this year a master thesis, in the Université catholique de Louvain in Belgium, about measuring the utility brought to the Tor network diversity by adding a new relay, according to its configuration. I added to this message my master thesis plan, as well as a poster that presents a summary of the key elements. May I ask you advices/feedback about this master thesis plan? Since I would like this project to bring a real contribution to the Tor development, I want to make sure that all the steps I will perform are useful and/or worth it. The master thesis plan: https://drive.google.com/open?id=1XEOSS29owavKJ_cJJAVaPiJe34Ez6XXx The poster: https://drive.google.com/open?id=1BlF2U-Kexyz6ihVSqvsVHv4PUsvXATc4 Thanks, Robin Descamps

3 2

Did tor-wiki-changes ML break?
by nusenu 03 Jan '18

03 Jan '18

Hi Damian, it appears to be the case that wiki changes are no longer send to this ML. Could you have a look? https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-wiki-changes thank you! nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

3 7

trac.tpo issues
by nusenu 24 Dec '17

24 Dec '17

Hi, in the last few days trac says occasionally "Service Unavailable" and right now trac times out. Since we are currently (attempting to) work on a wiki page, this is somewhat blocking our edits. Has trac some known issue? I'm looking forward to a reachable and stable trac :) thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev December 2017