Re: [tor-dev] Special-use-TLD support
On 09/29/2015 12:19 AM, Jeff Burdges wrote: > On Mon, 2015-09-28 at 16:26 -0400, Roger Dingledine wrote: >> On Mon, Sep 28, 2015 at 03:20:47PM +0200, Jeff Burdges wrote: >>> I proposed that Tor implement NameService rules using UNIX domain >>> sockets, or ports, since that's how GNUNet works, but maybe Tor >>> should >>> instead launch a helper application it communicates with via stdin >>> and >>> stdout. I donno if that'll work well on Windows however. >> >> If you're to be running a second program that does the "resolves", >> then >> I think you should really think about adding a third program that >> talks >> to Tor on the control port and does all of these rewrites via the >> control >> protocol without needing any further Tor modifications. (If you >> wanted, >> you could make these second and third programs be just one program.) >> >> This is I believe how Jesse's "OnioNS" tool works at present: you >> connect >> to the control port (e.g. via a Stem script), tell Tor that you want >> to >> decide what to do with each new stream (set __LeaveStreamsUnattached >> to >> 1), and then you let Tor pick (attachstream to 0) for all the streams >> except the special ones. When you see a new special stream, you do >> the >> lookup or resolve or whatever on your side, then REDIRECTSTREAM the >> stream to become the new address, then yield control of the stream >> back >> to Tor so Tor picks a circuit for it. >> >> The main downside here is that you need to run a new Tor controller. >> But >> if you're already needing to run a separate program, you should be >> all set. >> >> What am I missing? > > Very interesting. Yes, this sounds reasonable in the short run. In > the longer run, there are several people with an interest in > externalizing Tor's DNS handling, which changes things. I'll check out > OnioNS and discuss this with people at the meeting. Also, as you see from str4d's message, there are other projects interested in having a new name resolution *API* to access Namecoin, GNS, DNSSEC etc. Thus, it makes more sense to define a new name resolution service that all of those can use, instead of a Tor-specific hack. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] draft-grothoff-iesg-special-use-p2p-exit-00.xml
Dear all, Following https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ and the separation of .onion in https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01 to satisfy the IETF's desire to have lots of documents, I've now split off .exit as well to create draft-grothoff-iesg-special-use-p2p-exit-00 I've attached the current draft to this e-mail and would appreciate any feedback you may have. Also, if you feel that this is the wrong move entirely (i.e. because you don't want to reserve .exit), please do let me know ASAP and then I won't submit the draft. Happy hacking! Christian ?xml version=1.0 encoding=US-ASCII? !DOCTYPE rfc SYSTEM rfc2629.dtd [ !ENTITY RFC1034 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml; !ENTITY RFC1035 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml; !ENTITY RFC1928 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml; !ENTITY RFC2119 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml; !ENTITY RFC2308 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.2308.xml; !ENTITY RFC2629 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml; !ENTITY RFC3552 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml; !ENTITY RFC4648 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml; !ENTITY RFC5226 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml; !ENTITY RFC6761 SYSTEM http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml; !ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml; ] ?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ? ?rfc strict=yes ? ?rfc toc=yes ? ?rfc symrefs=yes? ?rfc sortrefs=yes ? ?rfc compact=yes ? ?rfc subcompact=no ? rfc category=info docName=draft-grothoff-iesg-special-use-p2p-exit-00 ipr=trust200902 front title abbrev=Special-Use-p2p-Exit The .exit Special-Use Domain Name of Tor /title author fullname=Christian Grothoff initials=C.G. surname=Grothoff organizationINRIA/organization address postal streetEacute;quipe Deacute;centraliseacute;e/street streetINRIA Rennes Bretagne Atlantique/street street263 avenue du Geacute;neacute;ral Leclerc/street streetCampus Universitaire de Beaulieu/street cityRennes/city regionBretagne/region codeF-35042/code countryFR/country /postal emailchrist...@grothoff.org/email /address /author author fullname=Matthias Wachs initials=M.W. surname=Wachs organizationTechnische Universitauml;t Muuml;nchen/organization address postal streetFree Secure Network Systems Group/street streetLehrstuhl fuer Netzarchitekturen und Netzdienste/street streetBoltzmannstrasse 3/street streetTechnische Universitaet Muenchen/street codeD-85748/code cityGarching bei Muenchen/city regionBayern/region countryDE/country /postal emailwa...@net.in.tum.de/email /address /author author fullname=Hellekin O. Wolf initials=H.O.W. role=editor surname=Wolf organizationGNU consensus/organization address emailhelle...@gnu.org/email /address /author author fullname=Jacob Appelbaum initials=J.A. surname=Appelbaum organizationTor Project Inc./organization address emailja...@appelbaum.net/email /address /author author fullname=Leif Ryge initials=L.R. surname=Ryge organizationTor Project Inc./organization address emaill...@synthesize.us/email /address /author date day=24 month=January year=2015 / !-- Meta-data Declarations -- areaGeneral/area workgroupInternet Engineering Task Force/workgroup keywordspecial-use/keyword keywordpeer-to-peer/keyword keyworddomain names/keyword keywordTor/keyword abstract tThis document registers a set of Special-Use Domain Names for use with the Tor Project, as per RFC6761./t /abstract /front middle section anchor=introduction title=Introduction tThe Domain Name System (DNS) is primarily used to map human-memorable names to IP addresses, which are used for routing but generally not meaningful for humans./t tThe Tor project supports the use of names to specify where the user wishes to exit the P2P overlay./t tAs compatibility with applications using domain names is desired, this mechanism requires an exclusive alternative Top-Level Domains to avoid conflict between the Tor namespace and the DNS hierarchy./t tIn order to avoid interoperability issues with DNS as well as to address
Re: [tor-dev] The Onion Name System (OnioNS)
On 05/23/2015 06:26 PM, OnioNS Dev wrote: My design also assumes that there is no dynamic compromise of Tor routers (there's no incentive for an attacker to target Tor routers because of OnioNS) I can live with explicitly stated design assumptions, but the claim that there is no incentive for an attacker to target Tor routers because of OnioNS is rather wild. With Namecoin, you have an inherent limit on the rate at which names can be registered. Now, once people start squatting tons of .tor names, maybe even your bandwidth advantage disappears as the consensus may become rather large. That's a fair point. It's a hard problem to solve. It's subtle, but I also put in a requirement that the network must also ensure that the registration points to an available hidden service. Thus it forces innocent users and attackers to also spin up a hidden service. It's not foolproof, but it's better than nothing. Interesting. Is a powerful adversary able to prevent registration by somehow denying/delaying access to the new .onion service and concurrently submitting a competing registration for the same name? I remember such attacks being discussed for DNS, where a candidate's search for available names might cause those to be quickly reserved by some automatism as a means to extort name re-assignment fees. Just wondering if you considered this possibility. (IIRC Namecoin defends against this by having an additional commit-and-reveal process where the name is first reserved without the name itself being revealed). I've also been thinking about a proof-of-stake solution wherein the network only accepts a registration if the destination HS has been up for X days. Can a HS have more than one name? Another idea is to have the Quorum select a random time during the week, test for the availability of the hidden service, and then sign whether they saw the HS or not. Then the next Quorum could repeat this test, check the results from the previous Quorum, and void the Record if they also observed that the hidden service was down. I like both of these ideas, but I have not yet solidified their implementation so I was not ready to announce them in the paper. Sure, good time to discuss them then ;-). Well, I prefer my hidden services to be really hidden and not public. I understand that this weakness is somewhat inherent in the design, but you should state it explicitly. Too late, your hidden services are already leaking across Tor's distributed hash table. Today, yes. Tomorrow, who knows; I'm still hoping that the next generation of HS will fix that, and hope try to get Tor to accept the GNS-method for encrypting information in the DHT. Which, btw, is pretty generic (we also use it in GNUnet-file sharing, and I have other plans as well). In fact, I think if you look at the GNS crypto closely, it might offer a way to encrypt most information in any DHT (and offer confidentiality against an adversary that cannot guess the name/label/keyword / perform a confirmation attack). There are even Tor technical reports and graphs on metrics.torproject.org which count them, which I assume also implies that they are enumerated. You are totally right about the status quo. I just would point out that this may not be true in 2020 ;-). It's not about CPU power, it's about the honesty of nodes in the Tor network. I understand that. But whether you do it on IPs, bandwidth or CPU, you did lower the bar on the adversary. That gives me the globally collision-free property. Perhaps I have lowered the bar, but I do think it's a bit higher than Namecoin because OnioNS is only dependent on the distribution of identities, and not the distribution of CPU power. I agree that it is probably easier to mount a 51% CPU-attack against Namecoin than an attack against the OnioNS quorum. Could we please make the protocol a bit more general than this? Yes, I will look into it. Your description is helpful, but if you want to write up a protocol describing what you want on your end, I'll merge it into my protocol, and then we'll have a protocol that is compatible with both of our needs. I would be happy to modify my software accordingly. I agree that we should have a write-up, but have to add that I hope to delegate most of the writing to Jeff ;-). Happy hacking! Christian signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The Onion Name System (OnioNS)
Please write an IETF draft asking for .tor to be reserved for Tor under RFC 6761 referencing your documentation. Should take no time if you base it on Jake's .onion draft. Send it to dnsop, they really love to discuss this topic and alternative DNS protocol ideas right now. ^_^. Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph). I'm not sure how your proposal significantly improves on NameCoin, except that it is specialized to Tor (and thus doesn't attempt to be as compatible with DNS as Namecoin): for security, you still rely on a PoW-supported consensus, so an adversary with sufficient computational power can register important names first (who gets facebook.tor first?). Given that you probably don't want to double the electicity bill of 'normal' users when they want to register names, my prediction is that if this is adopted, trolls (and name squatters) will have a field day registering interesting names. I didn't see a mechanism to transition a name from one RSA key/.onion address to another. Is that intentionally missing? Will users loose control over their .tor names when they rotate keys? It also seems you are unconcerned about zone enumeration. Both your protocol on authenticated denial-of-existence and the entire consensus system suggest that it should be easy for a peer to enumerate all names in the .tor zone. Why do you limit names to 128 characters, when DNS supports 253? With respect to Zooko's triangle, I would point out that you define it differently than GNS does (and we checked with Zooko about the definition at the time). In particular, you assume that the adversary has limited computational power and doesn't dominate the consensus. For GNS, we assume that PoW is useless (adversary can do PoW for all memorable names) and that consensus is useless (adversary has majority). This is because in practice, governments do have more computational power than citizens, and when it comes to censorship it is important to protect minorities and their opinions, not majorities. (see also http://grothoff.org/christian/fps2013wachs.pdf). Thus, you might want to make it clearer in your paper that you 'square' Zooko's triangle under exactly the same conditions as Namecoin: a weaker adversary model / definition of 'secure'. All that being said, I'm not at all against this: We should have MANY ways (protocols!) to assign names, some more usable, some more secure, especially as the current dominant method is just broken (DNS). So maybe Tor can plan to incorporate .tor, .bit (namecoin), .onion and .gnu. After all, each solution has interesting advantages and drawbacks. (The problem then only becomes educating the user about those.) Regardless, good luck with .gnu and I look forward to the resulting discussions on dnsop (IETF mailinglist), where you really should launch a discussion on this as well. On 05/19/2015 01:48 AM, OnioNS Dev wrote: Hello everyone, I'm the one behind the Onion Name System (OnioNS), a Tor-powered distributed DNS for Tor hidden services. It's been several weeks since my project was selected for the SoP program, and I've finally got around to posting here about it. My project aims to solve the major usability issue that has been with hidden services from the beginning: their un-memorable addresses. I'd like to discuss a bit about how it works, where my project is described, and where I am with the implementation. Under OnioNS, a hidden service operator can anonymously claim a meaningful domain name for their hidden service (a map between the .tor and .onion pseudo-TLDs) and then transmit it over a Tor circuit to an OnioNS server, which is also a Tor router. The claim propagates across the Tor network. Later, a user may type a .tor domain name into the Tor Browser. My software intercepts this domain, performs a lookup over a Tor circuit to an OnioNS node, and learns the corresponding .onion address. Then it tells the Tor client this, which contacts the HS in the normal way. The result of this process is that a hidden service loads transparently in the Tor browser under a meaningful name. I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor - onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum. Clients don't need a copy of the Pagechain to use the DNS, but
[tor-dev] Collecting data to demonstrate TCP ISN-based port knocking
Hi all, some of you might remember a project called Knock, which implements a variant of port-knocking in the Linux kernel that can be used to check the authenticity of arbitrary TCP connections and even can do integrity checking of the TCP payload by using a pre-shared key. Knock started as a student project which was presented during the Tor developer meeting at Technische Universität München last July. This was also where Jake added his two cents to help the project to move on. We still hope that Knock will be eventually useful for Tor (think: bridges), but could use your help to collect data to help convince the Linux people to adopt the latest patch. As Knock uses two fields in the TCP header in order to hide information and we explicitly want to be compatible with machines sitting in typical home networks, we need to make sure that this information doesn't get corrupted by the majority of NAT boxes out there. We thus created a program which tests if Knock would work in your environment. It would be great if some of you were able to execute the program on your machines in order to help us to get an estimation of if Knock one day could be used in a large scale. You can find sources, binaries and a more elaborate description here: https://gnunet.org/knock_nat_tester Technical details about Knock and a (somewhat outdated) research paper as well as kernel patches are provided here: https://gnunet.org/knock Best, Julian Christian 0x48426C7E.asc Description: application/pgp-keys ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Speeding Up Tor with SPDY
Dear all, Andrey Uzunov's Master's thesis on Speeding Up Tor with SPDY is now available at https://gnunet.org/content/speeding-tor-spdy My personal conclusions are that SPDY PUSH should not be used with Tor, and that modest performance gains with SPDY are attainable for typical websites. Aside from deployment considerations (how to detect exits supporting SPDY2HTTP translation), a major area for further work will be adding HTTP pipelining support to the SPDY2HTTP proxy to avoid performance regressions seen with some sites. For those that prefer watching over reading, we'll post the defense talk on https://gnunet.org/ once we've finished the conversion. Feedback is of course welcome. However, as Andrey is now finished with his thesis and looking for work (hire him!) -- and as I don't have any funding to support further work on this now -- it is unlikely that we'll be doing any further major implementation work on this in the near future. Naturally, the existing code is freely available (and does work, if one is willing to go through the pains to set it up properly). Happy hacking! Christian signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor and DNS
On 01/30/2012 07:59 AM, Roger Dingledine wrote: On Thu, Jan 19, 2012 at 05:13:19PM -0500, Nick Mathewson wrote: But I think the right design is probably something like allowing clients to request more DNS info via exit nodes' nameservers, and get more info back. We should think of ways to do this that avoid extra round trips, but that should be doable. So Nick, are you thinking we want a way for exit relays to receive an already-formatted dns query inside the Tor protocol, and get it onto the network somehow heading towards their configured nameservers? Or did you have something else in mind? I wonder if we want a begin_dns relay command, sort of like the current begin and begin_dir commands, and then just let them talk TCP to one of our nameservers? Or is that too much like the previous hacks? In GNUnet, we simply send the raw DNS payload over the mesh network to the exit node (in what for you would be a new cell type), the exit node sends it out via UDP to whatever DNS server the user provided, and the exit sends the response back to the initiator. So the exit never parses the DNS request or response at all. From what I've seen so far, 512 byte cells might do just fine 90% of the time, unless of course DNSSEC somehow takes off. However, GNUnet's message size limit is 64k, so this is not something I've been studying extensively. In cases where we need to parse DNS queries (likely outside of Tor's scope), we have our own library to do so, but even there we never parse DNS queries that did not originate from our own system. In summary, I think begin_dns is a good idea, but I'm not sure you need to then talk TCP to the nameserver -- UDP ought to suffice. My 2 cents Happy hacking! Christian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
