tor-dev

tor-dev@lists.torproject.org

3581 discussions

DNS proposal for Tor hidden services
by Jesse Victors 01 Aug '14

01 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everyone, I have a proposal for Tor hidden services, which if it's a good idea and workable I may be writing my Master's thesis on. My description here is very early, and I would like to run it by you guys before I continue further. I have already run it past Tor developers, but have seen limited response, so I'm opening it up to a wider audience. Basically, I propose integrating Namecoin into supporting Tor relays, so as to provide a secure DNS service for .onion sites within Tor itself. The result is that a human-readable address can be translated into its .onion counterpart, analogous to a domain name resolving into an IP address on the regular Internet, a square of Zooko's Triangle conjecture. Namecoin has a nearly identical codebase to Bitcoin, but instead of currency its primary focus is holding information, with a focus in DNS. Domains in Namecoin have the .bit extension, and registrations are secured with hashes in a blockchain. Anyone with the Namecoin blockchain can look up information in it, and indeed there are already Namecoin-supporting DNS servers that use the Namecoin blockchain to look up registrations in it. These basic premises are at the heart of my idea. Now, 3g2upl4pq6kufc4m.onion is the address for the DuckDuckGo hidden service, but it's hard to remember: even worse than a traditional IP address. Under my idea, a user could type in duckduckgo.tor, would see a secure translation to 3g2upl4pq6kufc4m.onion transparently and with masking, increasing the usability and popularity of hidden services significantly. My plan is in the context of Tor, to use the .tor domain, so as to not conflict with existing Namecoin registrations. The .onion address is a hash of the hidden service's public key, so if I own the private keys to 3g2upl4pq6kufc4m.onion, I should be able to sign something (perhaps the Namecoin public DSA key) to prove my ownership and set duckduckgo.tor.bit to point to 3g2upl4pq6kufc4m.onion. I then upload this to the Namecoin network as usual, (this costs 0.01 Namecoin) so that it becomes integrated into the blockchain. So now duckduckgo.tor.bit points to 3g2upl4pq6kufc4m.onion, and everyone with the blockchain knows it. Global DNS propagation may take less than 15 minutes. Namecoin domain registrations expire after 36,000 blocks (about 200 days) so a registration would have to be renewed occasionally for it to still remain. This is free to do, but ensures that domains don't endure indefinitely. It's impractical for Tor users to download the Namecoin blockchain in order to use this system, (even with Merkle trees) so instead supporting Tor relays can hold a copy and the Tor client can send out queries to them. At startup, Tor clients build several circuits through the network in preparation for use. Now let's say the user wants to look up duckduckgo.tor. To avoid spoofing attacks from a malicious relay, Tor clients will query multiple relays and gain a consensus. To do this, the Tor client generates three nonces, N1, N2, and N3. It then picks three random relays, possible trusted relays like guards, R1, R2, and R3. These relays have public RSA keys K1, K2, and K3, respectively. For each of the three relays, the Tor client takes the request for duckduckgo.tor, nonce Nj, and encrypts the pair with the relay's public key Kj. Along with a special new Tor flag specifying the use of this protocol, it then sends the trio through the circuit to the middle relay. The middle relay then queries the three relays. Each relay decrypts the request using its private key, checks the blockchain for duckduckgo.tor.bit, finds 3g2upl4pq6kufc4m.onion, and encrypts this answer with the nonce, and sends it back, signing the result. The client receives the answers, checks the signatures, decrypts the responses from the three relays using the nonces, and compares the response. If all three match, it then looks up 3g2upl4pq6kufc4m.onion in the traditional way. If two or less match, it restarts with a different set of three relays. If all three relays return that duckduckgo.tor can't be found, it throws the standard DNS error message. So I am simply building on top of the existing Tor hidden service infrastructure, not modifying it. I can write up a proposal for torspec.git once I have more details. I've already taken Tor 0.2.5.6-alpha code, installed Tor from source, and used Chutney to set up a mini Tor network on localhost of 5 authorities, 10 relays, and 1 client. That seems a good platform for development on this. What do you guys think about my proposal? Is this a good idea, and feasible? Anything I should watch out for as I go forward? What security threats exist that I should specifically defend against? Thank you for your time. - -- Jesse V. /CS, Network Security/ /Utah State University/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJT2BouXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA98MH/ih8VMQ8ZaKInYDDe3HBiU/s 9XBoGUT7ouXqnmtjSLjeTJjDfaNmLYBIRsAJTk8n/mJ7Zz9ld/5FW/QNKd1hAelE wtL4hKyVhS70fWVkFqZTLLyeVHVbegJx5sF2YdkDD6cJDU//KNbXTCO7A1Bx9vOu vPFoA+3ytlKcpx8HZn//k0mD7cB/dcS2GwSQmG2C+X0pWooJIsAJCgKyetbAaiHL ub/sd6Sr0bgkItGOi9vlAdPo+p7nNMWVxQQPfNqzz1zQJzE3WRXpXKmIYAOtngWp VT6SyrSkOmir/1+LN/s9d22VMaQKAzUVz21gbugBr64moeQW/IWbWBOQSbFA0J0= =8zWV -----END PGP SIGNATURE-----

2 1

[DRAFT] Proposal: All Routers are Directory Servers
by Matthew Finkel 01 Aug '14

01 Aug '14

Hi All, Below is a draft proposal for making all relays also be directory servers (by default). It's almost ready for a number, but it can use some feedback beforehand (give or take a few days). Tonight I also found that Nick actually created a similar proposal a few moons ago (Proposal 185: Directory caches without DirPort). This new proposal may benefit from superseding that one, but I recommend they remain distinct proposals, for now. In general I'm not tied to any of the proposed names, so suggestions are welcome. Thanks! ======================================================================= Filename: directory-servers-for-all.txt Title: All routers are directory servers Author: Matthew Finkel Created: 29-Jul-2014 Status: Draft Target: 0.2.6.x Overview: (In practice we refer to the servers that mirror directory documents as directory servers, directory mirrors, and directory caches. Sometimes we also shorten directory to dir. This proposal attempts to consistently use directory server to refer to this functionality. We also typically use the term router and relay interchangably. This proposal uses (onion) router.) This proposal aims at removing part of the distinction between the router and the directory server. Currently operators have the options of being one of: an onion router, a directory server, or both. With the acceptance of this proposal the options will be simplified to being either only a directory server or a combined router and directory server. All routers will serve directory requests. Motivation: Fetching directory documents and descriptors is sometimes a non-trivial operation for clients. If they do not have a consensus then they must contact a directory authority (until directory sources are added or clients are able to use a fallback consensus). If they have a consensus and have at least one entry guard then the client can query that guard for documents. If the document isn't available then after a period of time the client will attempt to retry downloading it. If the entry guard isn't a directory server, as well, a directory server and/or directory guard must be chosen (based on the server having an open DirPort) and queried for the document. At a minimum, this has a potential performance impact, at worst it's an attack vector that allows for profiling clients and partitioning users. With the orthogonally proposed move to clients using a single guard, the potential performance bottleneck and ability to profile users could be increased. If the client selects an entry guard and it is not a directory server then the client may select a distinct directory guard which will leak client behavior to a second node. In the case where the client does not use guards, it is important to have the largest possible amount of diversity in the set of directory servers. In a network where every router is a directory server, the profiling and partitioning attack vector is reduced to the guard (for clients who use them), which is already in a privileged position for this. In addition, with the increased set size, relay descriptors and documents are more readily available and it diversifies the providers. Design: The changes needed to achieve this should be simple. Currently all routers download and cache the majority of router documents in any case, so the slight increased memory usage from downloading all of them should have minimal consequences. There will be necessary logical changes in the client, router, and directory code. Currently directory servers are defined as such if they advertise having an open directory port. We can no longer assume this is true. To this end, we will introduce a new server descriptor line. "tunnelled-dir-server" The presence of this line indicates that the router accepts tunnelled directory requests. For a router that implements this proposal, this line MUST be added to its descriptor if it does not advertise a directory port, and MAY be added if it also advertises an open directory port. In addition to this, routers will now download and cache all descriptors and documents listed in the consensus, regardless of whether they are deemed useful or usable, exactly like the current directory servers. All routers will also accept directory requests when they are tunnelled over a connection established with a BEGIN_DIR cell, the same way these connections are already accepted by bridges and directory servers with an open DirPort. Directory Authorities will now assign the V2Dir flag to a server if it supports a version of the directory protocol which is useful to clients and it has at least an open directory port or it has an open OR port and advertises "tunnelled-dir-server" in its server descriptor. Clients choose a directory by using the current criteria with the additional qualification that a server only needs the V2Dir status flag instead of requiring an open DirPort. When the client chooses which directory server it will query, it checks if the server has an open directory port and uses begindir if it does not. This will minimize the increased number of clients that prefer begindir over direct connections and thus also minimizes the additional overhead on the network from clients establishing OR connections for directory requests. Security Considerations and Implications: Currently all directory servers are explicitly configured. This is necessary because they must have a configured and reachable external port. However, this is a restriction and results in a reduced number of directory servers on the network. As a result, this could allow an adversary to control a significant fraction of the servers. By increasing the number of directory servers on the network the likelihood of selecting one that is malicious is reduced. Also, with this proposal, it will be more likely that a client's entry guard is also a directory server (as alluded to in Proposal 207). However, the reduced anonymity set caused when the guard does not have, or is unwilling to distribute, a specific document still exists. With the increased diversity in the available servers, the impact of this should be reduced. Another question that may need further consideration is whether we trust bad directories to be good guards and exits. Specification: The version 3 directory protocol specification does not currently document the use of directory guards. This spec should be updated to mention the preferred use of directory guards during directory requests. In addition, the new criteria for assigning the V2Dir flag should be documented. Considerations for Resource Constrained Hardware: If all routers become directory servers, they will choose to download all documents, regardless of whether they are useful, in case another client does want them. This will have very little impact on the "typical" router, however on memory constrained routers (Raspberry Pi and similar), every kilobyte allocated to directory documents is not available for new circuits. Should we add a config option that allows operators to disable being a directory server? Is it more worthwhile for them to serve these documents or to relay cells? Future Considerations: Should the DirPort be deprecated at some point in the future?

2 2

[android dev] probably a stupid noob question… but
by CJ 31 Jul '14

31 Jul '14

… how may I add netcipher lib to an Android Studio project? I've searched on the Net, but nothing seems to match my needs :( sorry for this stupid question, but I'm a bit stuck (yes, first android app, blah)… Cheers, C.

3 3

Pluggable transports meeting tomorrow (16:00UTC Friday 1st of August 2014)
by George Kadianakis 31 Jul '14

31 Jul '14

Hello brothers and sisters, just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks!

1 0

Centos 7
by obx 30 Jul '14

30 Jul '14

hi, is somebody working on a rpm for centos 7? Is there an ETA? Thanks in advance.

2 1

Email Bridge Distributor Interactive Commands
by Matthew Finkel 30 Jul '14

30 Jul '14

Hi everyone, A short time ago BridgeDB learned how to accept some more commands via email[0]. Below is an example of the current help/overview autoresponse email[1] that users receive (in English, we do have translations). These commands may not be optimal, so we'd love to be given feedback on this so we can improve it. Currently, with the recent changes, we require all commands begin with 'get' and then we check which keyword follows it ('bridges', 'transport', 'help', 'key', etc). This certainly makes the parsing logic easy (and I am a fan of KISS), but it may be true that this is a bit too strict and decreases its usability. Would it be better if we were more lax? For example, instead of requiring: 'get transport <TYPE>' we change this to: '[[get] transport] <TYPE>' Therefore the 'get' and 'transport' keywords are optional (and 'get' is only used if you use 'transport'). <TYPE> is the pluggable tranport method name you want the bridges to support. I think this simplifies the user interaction but I don't know if it's significant and to what extent most users care about this. It should be mentioned that prior to the recent changes, sending a blank email to bridges(a)bridges.torproject.org was equivilent to sending an email that contained 'get bridges' because we didn't actually check for 'get bridges' at all, we do this now, though. So, the questions I am posing to those in the community who has an opinion about this: What do you think? What problems do you currently have with this? How can this be improved? Thanks! Matt [0] https://trac.torproject.org/projects/tor/ticket/7550 [1] > Hey, <you>! Welcome to BridgeDB! > > > > COMMANDs: (combine COMMANDs to specify multiple options simultaneously) > get bridges Request vanilla bridges. > get transport [TYPE] Request a Pluggable Transport by TYPE. > get help Displays this message. > get key Get a copy of BridgeDB's public GnuPG key. > get ipv6 Request IPv6 bridges. > > Currently supported transport TYPEs: > obfs2 > obfs3 > scramblesuit > > > BridgeDB can provide bridges with several types of Pluggable Transports[0], > which can help obfuscate your connections to the Tor Network, making it more > difficult for anyone watching your internet traffic to determine that you are > using Tor. > > Some bridges with IPv6 addresses are also available, though some Pluggable > Transports aren't IPv6 compatible. > > Additionally, BridgeDB has plenty of plain-ol'-vanilla bridges - without any > Pluggable Transports - which maybe doesn't sound as cool, but they can still > help to circumvent internet censorship in many cases. > > [0]: https://www.torproject.org/docs/pluggable-transports.html > > -- > <3 BridgeDB > ______________________________________________________________________ > Public Keys: https://bridges.torproject.org/keys > This email was generated with rainbows, unicorns, and sparkles > for your(a)email.com on Sunday, 20 July, 2014 at 16:59:19. >

12 34

Working on a Globe Fork
by William Papper 29 Jul '14

29 Jul '14

Hi all, I'm a freelance web designer and developer, and I'm working on a fork of Globe after seeing the recent blog post <https://blog.torproject.org/blog/looking-front-end-web-developers-network-s…> on the Tor Project's website. Since none of the other forks have any changes or are actively maintained, I created a fork on GitHub here <https://github.com/wpapper/globe> . I'm going to start by improving the responsive aspects of the design, and also clean up some unclear design decisions (e.g. Changing to something more descriptive than "keyword" for the search box and removing some redundant UI elements). I'll be making GitHub issues for the changes that need to be made. Anyone else can add any issues they see there. If you'd like to help contribute, just take on an issue and submit a pull request. Of course, let me know if you have any comments or suggestions. Sincerely, Will Papper

1 0

orbot: get its ports from another app
by CJ 29 Jul '14

29 Jul '14

Hello, I'm currently developping orwall, a UI over iptables allowing to block all IP traffic and forcing selected apps through Orbot (while blocking the others), among other things. I'm wondering if there's a way to ask Orbot, if installed, its SOCKS and TransPort configuration. I think NetCipher lib may do it, but I'm not that sure. Thanks in advance for your answer/help :). Cheers, C.

2 2

GSoc Stegotorus status update
by Noah Rahman 29 Jul '14

29 Jul '14

Sorry for the delay, I have been travelling for the past week and a half and was at HOPE. I have finished debugging the swf steg, and am hunting down the last bugs in the pdf steg. SRI advised me that they are still working on their JavaScript transcoding library they wish to plug into the SWF and JS stegs, so I will move the JS steg and JSON stegs over but at the unti tests for JSON first. By the time of the PT meeing on August 1st I intend: to have JS, SWF and PDF debugged with unit tests finish testing the handshake code and make it robust to packets arriving out of order (discussed ideas for this in person with vmon) be ready to start debugging the transparent proxy start sketching out how to incorporate the JSON steg and the SRI jel library (if they get it finished in the next two weeks) Best Noah

1 0

Please merge these anti-fingerprinting bugfixes
by faether 28 Jul '14

28 Jul '14

Can a TBB developer please push these very simple but important anti- fingerprinting prefs through: pref("full-screen-api.enabled", false); pref("browser.link.open_newwindow.restriction", 0); pref("dom.disable_window_move_resize", true); Fixing: https://trac.torproject.org/projects/tor/ticket/12609 (two weeks old) https://trac.torproject.org/projects/tor/ticket/9881 (ten months old) I've written a proposal to treat fingerprinting related bugfixes like other security bugfixes with regards to urgency and release management: https://trac.torproject.org/projects/tor/ticket/12715

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev