- tor-dev - lists.torproject.org

Re: [tor-dev] The Onion Name System (OnioNS)
by OnioNS Dev 20 May '15

20 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/19/2015 03:20 AM, tor-dev-request(a)lists.torproject.org wrote: > Subject: > Re: [tor-dev] The Onion Name System (OnioNS) > From: > Christian Grothoff <grothoff(a)gnunet.org> > Date: > 05/19/2015 03:24 AM > > To: > tor-dev(a)lists.torproject.org > > > 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. ^_^. I will put that on the to-do list. > Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph). Thanks, I'll make those corrections. Good to hear from someone who is part of that system. > 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. My scheme is better than Namecoin in several key ways: 1) No miners. I'm relying on the existing trust of the Tor network and purposely did not create a new network. 2) Minimal networking costs. Namecoin typically requires users to hold the blockchain, and has very little client-side security when users rely on name servers to hold it for them. I require clients to check a set of signatures from Tor routers. Most of the attack vectors for OnioNS also results in a compromise of Tor, which makes the whole thing moot. Hence it makes sense to rely on Tor. The PoW is only for registration, no one else does it. Yes, it is first-come-first-serve, but so is Namecoin. On the Internet DNS, someone with lots of money could buy up domains too (ISPs do this all the time). For well-known hidden services (such as DuckDuckGo) we could mark those names as reserved such that only the owner of that hidden service could register it on OnioNS, and let all other names be first-come-first-serve. I'm thinking of setting the proof-of-work relatively high, say four hours on an i7 or so. The reliance on scrypt and the complex of the domain registration should restrict this to CPUs. > 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? I only have 12 pages, there wasn't enough space for that protocol. However, I have already created protocols for deleting, transferring, and updating Records. Domain registration uses the same private key as hidden services, so if the key is compromised, both are compromised and the security of the Record is moot. > 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. I'm considering that all OnioNS data is public. There's no way to hide information in the Pagechain as Mirrors need to verify it. An attacker could also spin up a machine, synchronize with the network, and enumerate them anyway. Clients must also see the domain names in the leaves of the Merkle tree in order to authenticate Records or verify that the domain does not exist by finding two domains that alphabetically span it. I also can't hide the domain names in the Merkle trees via hashes because then I'm mapping unique names to a binary space that may have collisions. It's far easier to just consider the information public. Fortunately, there's no personally-identifiable information in the Pagechain, so there's no advantage in hiding the data. > Why do you limit names to 128 characters, when DNS supports 253? For space reasons. Longer names introduce more storage and networking demands. The smaller choice shouldn't make any practical difference; I have yet to see a domain name on the Internet with a 253-character second-level domain. > 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'. I think you may misunderstand. Computational power (PoW) here has nothing to do with Zooko's Triangle. With Namecoin, the network is assumed to have more CPU power than adversaries and thus they can achieve all three properties. Here, PoW is only used to increase the difficulty of claiming a domain name, and I get the uniqueness property because I assume that Tor routers are generally honest. This is a safe assumption as if Tor routers weren't honest, Tor circuits would not provide privacy and again the whole system breaks and becomes moot. So, I assume that Tor routers follow the rules and reject duplicate domain names, therefore the network as a whole prevents collisions. An attacker could win here by Sybil attack by spinning up many new Tor routers and gaining control of the Quorum by placing the statistics in their favor. My analysis shows that this is extremely unlikely for L_Q >= 127. > 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). Glad to have your support. I agree that the Internet DNS is broken. It was never designed with security in mind in the first place; there was no need to because originally everyone knew each other. :) > 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. Yawning mentioned this. It's easy enough to create a spec that defines the protocol for handling other pseudo-TLDs. Currently Tor writes "*.tor" to a named pipe, reads "*.onion", and finishes the lookup. It's easy to use that protocol for any alternative DNS. It's outside Tor's scope to care how the *.tor -> *.onion map is accomplished. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVW26lAAoJEK2XNk/CC+yA+1MH/3HNANFFzhCs567B8XkcHu0M VijH8dD6f+ClxuxVFmjKb5c9jlgK5vW9E+LsFiUFbT3vHdjZxh4nH4zNv1FnVIxc RnkNvuhXGYpDCSRFNtvqa1ZPwOj3ENBvB8++wB/M2DM3KN4B6dKXdHNgjfMDNfji L62o23ApQaKOu8vi0wr9VNLTCbji9LS0GerR5G7mUMAUo194WjBGhNwhBQknCeze RACjHnRjfqDWSyszgI7e0xKNK3rGOzQWIPwlScqnl1LEh6tWaxMZDmzN+FHr2QbG C5Sb1fDywKeVCQdBSAjAS++WvzvYNbiFExaJ9ucVWMPMdjrxjDzpHrVM8P/xWaY= =6kyi -----END PGP SIGNATURE-----

2 1

Re: [tor-dev] Namecoin .onion to .bit linking
by OnioNS Dev 19 May '15

19 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > On 05/19/2015 10:02 AM, Daniel Martí wrote: >> I'm not familiar with Namecoin, but I thought I'd just point out >> that someone will be working on OnioNS, the onion name system, as >> part of the SoP in Tor. The person who will be working on it just >> sent an e-mail to this very list yesterday. >> >> You two seem to be after the same "human-readable way to access >> .onion domain names" target as you yourself described, so there >> might be room for collaboration. > I'm aware of OnioNS, but haven't yet had time to thoroughly read the > proposal. It's certainly on my to-do list, if nothing else for > cross-pollination of ideas. > > - -Jeremy Yes, I'm here. Last year I explored Namecoin as a possible alternative DNS for Tor hidden services. I spent some time over it, but I also ran into the same problems previously mentioned above: how to link HS RSA keys to Namecoin ECDSA keys. I came up with two solutions: sign the Namecoin key with the HS key and embed that signature in the blockchain, or introduce a new blockchain that relied on the same cryptography as hidden services (RSA, Ed25519, ECDSA, etc, as long as they matched). As I mentioned in the ACM paper, it's non-trivial to build this correlation and I came to the conclusion that solutions would look more like a hack than an elegant solution. Moreover, even if the correlation could be built, it's impractical to require clients to download the whole blockchain before use, so you still have to address the issue of preventing name servers from lying. I hope you can see that it's a difficult problem. I think Namecoin could use a solution if you come up with one, and I would be interested in hearing about it. I came to the conclusion that Namecoin would not work and wrote something different. Namecoin does many things well and I took those good design ideas, but I also changed the setup to solve many of its weaknesses. Namecoin, GNS, and OnioNS are good alternative DNSs, each with their own approach. Let's see if we can work together here, we might be able to help one another. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVW52lAAoJEK2XNk/CC+yAUtQH/1a9zZQK2XYsQofGt+qtrAA0 MZmBHMTC+lBLcpq1ZSIYCD+vJ8DEO1Aoqrzfj7RVsS5T1dfXZ5B4D+u2XB+Obg1+ uW86/cWQ3S2UgFRg5Mg0+6C+3T7sIwBya3foXg0/dETh4R9J2QzSG7iobsvjuivr TEUh7iGl+9zBDHad3s5ZZRBms9ZHk4fQy1ckFx6h9bvh5ybzaZZKc8bAYdRF1yTi RQw4MmtoJ4e2MZf7Ze9qVn863KOLQQzOlw0ddQ4tCLpHfBwr+l+lK5waGflVYLjU C2RVt9QUS83PgDXY3sKp+kIlfqp0Oupf7ZFqq6xAHWIHORvcr8vERtFadWLiQVw= =vl1G -----END PGP SIGNATURE-----

2 1

The Onion Name System (OnioNS)
by OnioNS Dev 19 May '15

19 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 rather they can just rely on their existing trust of the Tor network (including the Quorum and name servers) and verify their signatures on data structures. Also unlike a blockchain, my Pagechain has a finite length: the oldest Page will eventually drop off, which forces domains to be renewed periodically. I have also introduced mechanisms that 1) allows clients to authenticate the domain name to the hidden service, 2) allow clients to authenticate a denial-of-existence claim from a name server, and 3) prevent name servers from forging .tor -> .onion associations. These vulnerabilities are still generally open on the Internet DNS. I have also tried to minimize networking costs, since Tor circuits are slow. To reduce CPU and network requirements, I want Tor routers to have Ed25519 keys. Let this project add additional pressure on that item on the to-do list. Recommended readings: http://onions55e7yam27n.onion -- the official hidden service for this project, but a work in progress. https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf -- the ACM paper pending peer review I no longer recommending reading my original thesis, please use the above links instead. My prototype can be found here: https://github.com/Jesse-V/OnioNS It's a bit unstable, but it does work once and sometimes twice. Please contact me (kernelcorn on IRC) before running the prototype, I need to ensure that the name server is up before you can try it out. You can also send me registrations over IRC and I can add them in. I am asking for help with the client-side functionality. I'm currently doing the *.tor interception and lookup resume in connection_edge.c but the software frequently crashes with this approach, (I've learned why) and I'd like to migrate it to Stem for now. I need to intercept .tor domains, pause the lookup (letting the Tor Browser spin), send the hostname over a named pipe or TCP socket, read back a .onion address, then tell Tor to resume the lookup under the .onion address. This way, the HS loads under a .tor domain. All other lookups should load as normal. I've never used Stem before but I understand using it will be a lot easier than hacking Tor. I have Stem up and running now. Any recommendations for what I'm trying to do here? - -- Jesse V. (kernelcorn) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVWnpiAAoJEK2XNk/CC+yA0MsH/Ahg3V1U+bIRqawmVu5Ju85C gAqVqJx3pYsJPDHpmZU2OGICGIAWVMS0d8wA39H42MBJG3AP/1PGevlB8tK+/i5K t/o3vLTt9WpuxL3Lf2+VihlDTFnUSQz+02pMyghwjS3ANoutoLb2wMB/EeSn74FS ozLjEkO7fbyEx1Qzp4xDHKNjfRBmkn2k83O9YhEPZ6d6VYFHrCfsygd6XvHpuPzT XLu3OyamFeT5BjZgkX2gge+zG9UUOmDLC2aCQa83gHxcty3Sdh5aZ33oVfx9bROU +AaD2yAbLNaq/mEmp2qaAOnsQCzBTrRJ5CX9jyLvCOVYi3SZtl/4Ju/oomWqHl0= =TvQm -----END PGP SIGNATURE-----

3 2

FTBFS for ooniprobe on Fedora 21
by Jacek Wielemborek 18 May '15

18 May '15

Hello, Below is the log. Am I missing some package or something? [1:07:53][~][1] $ sudo pip install ooniprobe zsh: correct 'pip' to '.pip' [nyae]? n Downloading/unpacking ooniprobe Downloading ooniprobe-1.2.2.tar.gz (13.4MB): 13.4MB downloaded Running setup.py (path:/tmp/pip-build-YH9MXT/ooniprobe/setup.py) egg_info for package ooniprobe /usr/share/GeoIP/GeoIPASNum.dat already exists. Skipping. /usr/share/GeoIP/GeoIP.dat already exists. Skipping. /usr/share/GeoIP/GeoLiteCity.dat already exists. Skipping. warning: no files found matching 'data/inputs/' Requirement already satisfied (use --upgrade to upgrade): PyYAML>=3.10 in /usr/lib64/python2.7/site-packages (from ooniprobe) Requirement already satisfied (use --upgrade to upgrade): Twisted>=12.2.0 in /usr/lib64/python2.7/site-packages (from ooniprobe) Downloading/unpacking ipaddr>=2.1.10 (from ooniprobe) Downloading ipaddr-2.1.11.tar.gz Running setup.py (path:/tmp/pip-build-YH9MXT/ipaddr/setup.py) egg_info for package ipaddr Requirement already satisfied (use --upgrade to upgrade): pyOpenSSL>=0.13 in /usr/lib64/python2.7/site-packages (from ooniprobe) Requirement already satisfied (use --upgrade to upgrade): geoip in /usr/lib64/python2.7/site-packages (from ooniprobe) Downloading/unpacking txtorcon>=0.7 (from ooniprobe) Downloading txtorcon-0.11.0-py2-none-any.whl (175kB): 175kB downloaded Downloading/unpacking txsocksx>=0.0.2 (from ooniprobe) Downloading txsocksx-1.13.0.3.tar.gz Running setup.py (path:/tmp/pip-build-YH9MXT/txsocksx/setup.py) egg_info for package txsocksx zip_safe flag not set; analyzing archive contents... Installed /tmp/pip-build-YH9MXT/txsocksx/vcversioner-2.14.0.0-py2.7.egg Downloading/unpacking parsley>=1.1 (from ooniprobe) Downloading Parsley-1.2.tar.gz (275kB): 275kB downloaded Running setup.py (path:/tmp/pip-build-YH9MXT/parsley/setup.py) egg_info for package parsley Downloading/unpacking scapy-real>=2.2.0-dev (from ooniprobe) Downloading scapy-real-2.2.0-dev.tar.gz (1.1MB): 1.1MB downloaded Running setup.py (path:/tmp/pip-build-YH9MXT/scapy-real/setup.py) egg_info for package scapy-real Downloading/unpacking pypcap>=1.1 (from ooniprobe) Downloading pypcap-1.1.1.tar.gz (44kB): 44kB downloaded Running setup.py (path:/tmp/pip-build-YH9MXT/pypcap/setup.py) egg_info for package pypcap Found pcap headers in /usr/include/pcap/pcap.h Found libraries in /usr/lib64/libpcap.so found pcap_setnonblock found pcap_compile_nopcap function found pcap_file function Downloading/unpacking service-identity (from ooniprobe) Downloading service_identity-14.0.0-py2.py3-none-any.whl Requirement already satisfied (use --upgrade to upgrade): zope.interface>=3.6.1 in /usr/lib64/python2.7/site-packages (from txtorcon>=0.7->ooniprobe) Requirement already satisfied (use --upgrade to upgrade): pyasn1 in /usr/lib/python2.7/site-packages (from service-identity->ooniprobe) Downloading/unpacking pyasn1-modules (from service-identity->ooniprobe) Downloading pyasn1-modules-0.0.5.tar.gz Running setup.py (path:/tmp/pip-build-YH9MXT/pyasn1-modules/setup.py) egg_info for package pyasn1-modules Downloading/unpacking characteristic>=14.0.0 (from service-identity->ooniprobe) Downloading characteristic-14.3.0-py2.py3-none-any.whl Requirement already satisfied (use --upgrade to upgrade): setuptools in /usr/lib/python2.7/site-packages (from zope.interface>=3.6.1->txtorcon>=0.7->ooniprobe) Installing collected packages: ooniprobe, ipaddr, txtorcon, txsocksx, parsley, scapy-real, pypcap, service-identity, pyasn1-modules, characteristic Running setup.py install for ooniprobe /usr/share/GeoIP/GeoIPASNum.dat already exists. Skipping. /usr/share/GeoIP/GeoIP.dat already exists. Skipping. /usr/share/GeoIP/GeoLiteCity.dat already exists. Skipping. changing mode of build/scripts-2.7/oonideckgen from 644 to 755 changing mode of build/scripts-2.7/ooniprobe from 644 to 755 changing mode of build/scripts-2.7/oonireport from 644 to 755 changing mode of build/scripts-2.7/ooniresources from 644 to 755 warning: no files found matching 'data/inputs/' changing mode of /usr/bin/ooniresources to 755 changing mode of /usr/bin/oonireport to 755 changing mode of /usr/bin/ooniprobe to 755 changing mode of /usr/bin/oonideckgen to 755 Running setup.py install for ipaddr Running setup.py install for txsocksx Running setup.py install for parsley Running setup.py install for scapy-real changing mode of build/scripts-2.7/scapy from 644 to 755 changing mode of build/scripts-2.7/UTscapy from 644 to 755 changing mode of /usr/bin/UTscapy to 755 changing mode of /usr/bin/scapy to 755 Running setup.py install for pypcap Found pcap headers in /usr/include/pcap/pcap.h Found libraries in /usr/lib64/libpcap.so found pcap_setnonblock found pcap_compile_nopcap function found pcap_file function building 'pcap' extension gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DHAVE_PCAP_INT_H=1 -DHAVE_PCAP_SETNONBLOCK=1 -DHAVE_PCAP_COMPILE_NOPCAP=1 -DHAVE_PCAP_FILE=1 -I/usr/include/pcap -I/usr/include/python2.7 -c pcap.c -o build/temp.linux-x86_64-2.7/pcap.o pcap.c: In function ‘__pyx_pf_4pcap_3bpf_2filter’: pcap.c:1395:52: warning: passing argument 2 of ‘PyObject_AsCharBuffer’ from incompatible pointer type __pyx_t_1 = ((PyObject_AsCharBuffer(__pyx_v_buf, (&__pyx_v_p), (&__pyx_v_n)) < 0) != 0); ^ In file included from /usr/include/python2.7/Python.h:133:0, from pcap.c:16: /usr/include/python2.7/abstract.h:476:22: note: expected ‘const char **’ but argument is of type ‘char **’ PyAPI_FUNC(int) PyObject_AsCharBuffer(PyObject *obj, ^ pcap.c:1395:66: warning: passing argument 3 of ‘PyObject_AsCharBuffer’ from incompatible pointer type __pyx_t_1 = ((PyObject_AsCharBuffer(__pyx_v_buf, (&__pyx_v_p), (&__pyx_v_n)) < 0) != 0); ^ In file included from /usr/include/python2.7/Python.h:133:0, from pcap.c:16: /usr/include/python2.7/abstract.h:476:22: note: expected ‘Py_ssize_t *’ but argument is of type ‘int *’ PyAPI_FUNC(int) PyObject_AsCharBuffer(PyObject *obj, ^ pcap.c:1416:58: warning: pointer targets in passing argument 2 of ‘bpf_filter’ differ in signedness [-Wpointer-sign] __pyx_t_1 = ((bpf_filter(__pyx_v_self->fcode.bf_insns, __pyx_v_p, __pyx_v_n, __pyx_v_n) == 0) != 0); ^ In file included from /usr/include/pcap/pcap.h:49:0, from pcap.c:343: /usr/include/pcap/bpf.h:1474:14: note: expected ‘const u_char *’ but argument is of type ‘char *’ extern u_int bpf_filter(const struct bpf_insn *, const u_char *, u_int, u_int); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_16dispatch’: pcap.c:3135:68: warning: passing argument 3 of ‘pcap_dispatch’ from incompatible pointer type __pyx_v_n = pcap_dispatch(__pyx_v_self->__pyx___pcap, __pyx_t_1, __pyx_f_4pcap___pcap_handler, ((unsigned char *)(&__pyx_v_ctx))); ^ In file included from pcap.c:343:0: /usr/include/pcap/pcap.h:373:5: note: expected ‘pcap_handler’ but argument is of type ‘void (*)(void *, struct pcap_pkthdr *, char *)’ int pcap_dispatch(pcap_t *, int, pcap_handler, u_char *); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_18loop’: pcap.c:3364:74: warning: passing argument 3 of ‘pcap_ex_next’ from incompatible pointer type __pyx_v_n = pcap_ex_next(__pyx_v_self->__pyx___pcap, (&__pyx_v_hdr), (&__pyx_v_pkt)); ^ In file included from pcap.c:344:0: pcap_ex.h:13:7: note: expected ‘u_char **’ but argument is of type ‘char **’ int pcap_ex_next(pcap_t *pcap, struct pcap_pkthdr **hdr, u_char **pkt); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_20sendpacket’: pcap.c:3619:61: warning: pointer targets in passing argument 2 of ‘pcap_sendpacket’ differ in signedness [-Wpointer-sign] __pyx_v_ret = pcap_sendpacket(__pyx_v_self->__pyx___pcap, __pyx_t_1, __pyx_t_2); ^ In file included from pcap.c:343:0: /usr/include/pcap/pcap.h:384:5: note: expected ‘const u_char *’ but argument is of type ‘char *’ int pcap_sendpacket(pcap_t *, const u_char *, int); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_28__next__’: pcap.c:3976:74: warning: passing argument 3 of ‘pcap_ex_next’ from incompatible pointer type __pyx_v_n = pcap_ex_next(__pyx_v_self->__pyx___pcap, (&__pyx_v_hdr), (&__pyx_v_pkt)); ^ In file included from pcap.c:344:0: pcap_ex.h:13:7: note: expected ‘u_char **’ but argument is of type ‘char **’ int pcap_ex_next(pcap_t *pcap, struct pcap_pkthdr **hdr, u_char **pkt); ^ gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DHAVE_PCAP_INT_H=1 -DHAVE_PCAP_SETNONBLOCK=1 -DHAVE_PCAP_COMPILE_NOPCAP=1 -DHAVE_PCAP_FILE=1 -I/usr/include/pcap -I/usr/include/python2.7 -c pcap_ex.c -o build/temp.linux-x86_64-2.7/pcap_ex.o pcap_ex.c:18:23: fatal error: pcap-int.h: No such file or directory # include <pcap-int.h> ^ compilation terminated. error: command 'gcc' failed with exit status 1 Complete output from command /usr/bin/python -c "import setuptools, tokenize;__file__='/tmp/pip-build-YH9MXT/pypcap/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-X1iDfG-record/install-record.txt --single-version-externally-managed --compile: Found pcap headers in /usr/include/pcap/pcap.h Found libraries in /usr/lib64/libpcap.so found pcap_setnonblock found pcap_compile_nopcap function found pcap_file function running install running build running build_ext building 'pcap' extension creating build creating build/temp.linux-x86_64-2.7 gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DHAVE_PCAP_INT_H=1 -DHAVE_PCAP_SETNONBLOCK=1 -DHAVE_PCAP_COMPILE_NOPCAP=1 -DHAVE_PCAP_FILE=1 -I/usr/include/pcap -I/usr/include/python2.7 -c pcap.c -o build/temp.linux-x86_64-2.7/pcap.o pcap.c: In function ‘__pyx_pf_4pcap_3bpf_2filter’: pcap.c:1395:52: warning: passing argument 2 of ‘PyObject_AsCharBuffer’ from incompatible pointer type __pyx_t_1 = ((PyObject_AsCharBuffer(__pyx_v_buf, (&__pyx_v_p), (&__pyx_v_n)) < 0) != 0); ^ In file included from /usr/include/python2.7/Python.h:133:0, from pcap.c:16: /usr/include/python2.7/abstract.h:476:22: note: expected ‘const char **’ but argument is of type ‘char **’ PyAPI_FUNC(int) PyObject_AsCharBuffer(PyObject *obj, ^ pcap.c:1395:66: warning: passing argument 3 of ‘PyObject_AsCharBuffer’ from incompatible pointer type __pyx_t_1 = ((PyObject_AsCharBuffer(__pyx_v_buf, (&__pyx_v_p), (&__pyx_v_n)) < 0) != 0); ^ In file included from /usr/include/python2.7/Python.h:133:0, from pcap.c:16: /usr/include/python2.7/abstract.h:476:22: note: expected ‘Py_ssize_t *’ but argument is of type ‘int *’ PyAPI_FUNC(int) PyObject_AsCharBuffer(PyObject *obj, ^ pcap.c:1416:58: warning: pointer targets in passing argument 2 of ‘bpf_filter’ differ in signedness [-Wpointer-sign] __pyx_t_1 = ((bpf_filter(__pyx_v_self->fcode.bf_insns, __pyx_v_p, __pyx_v_n, __pyx_v_n) == 0) != 0); ^ In file included from /usr/include/pcap/pcap.h:49:0, from pcap.c:343: /usr/include/pcap/bpf.h:1474:14: note: expected ‘const u_char *’ but argument is of type ‘char *’ extern u_int bpf_filter(const struct bpf_insn *, const u_char *, u_int, u_int); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_16dispatch’: pcap.c:3135:68: warning: passing argument 3 of ‘pcap_dispatch’ from incompatible pointer type __pyx_v_n = pcap_dispatch(__pyx_v_self->__pyx___pcap, __pyx_t_1, __pyx_f_4pcap___pcap_handler, ((unsigned char *)(&__pyx_v_ctx))); ^ In file included from pcap.c:343:0: /usr/include/pcap/pcap.h:373:5: note: expected ‘pcap_handler’ but argument is of type ‘void (*)(void *, struct pcap_pkthdr *, char *)’ int pcap_dispatch(pcap_t *, int, pcap_handler, u_char *); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_18loop’: pcap.c:3364:74: warning: passing argument 3 of ‘pcap_ex_next’ from incompatible pointer type __pyx_v_n = pcap_ex_next(__pyx_v_self->__pyx___pcap, (&__pyx_v_hdr), (&__pyx_v_pkt)); ^ In file included from pcap.c:344:0: pcap_ex.h:13:7: note: expected ‘u_char **’ but argument is of type ‘char **’ int pcap_ex_next(pcap_t *pcap, struct pcap_pkthdr **hdr, u_char **pkt); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_20sendpacket’: pcap.c:3619:61: warning: pointer targets in passing argument 2 of ‘pcap_sendpacket’ differ in signedness [-Wpointer-sign] __pyx_v_ret = pcap_sendpacket(__pyx_v_self->__pyx___pcap, __pyx_t_1, __pyx_t_2); ^ In file included from pcap.c:343:0: /usr/include/pcap/pcap.h:384:5: note: expected ‘const u_char *’ but argument is of type ‘char *’ int pcap_sendpacket(pcap_t *, const u_char *, int); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_28__next__’: pcap.c:3976:74: warning: passing argument 3 of ‘pcap_ex_next’ from incompatible pointer type __pyx_v_n = pcap_ex_next(__pyx_v_self->__pyx___pcap, (&__pyx_v_hdr), (&__pyx_v_pkt)); ^ In file included from pcap.c:344:0: pcap_ex.h:13:7: note: expected ‘u_char **’ but argument is of type ‘char **’ int pcap_ex_next(pcap_t *pcap, struct pcap_pkthdr **hdr, u_char **pkt); ^ gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DHAVE_PCAP_INT_H=1 -DHAVE_PCAP_SETNONBLOCK=1 -DHAVE_PCAP_COMPILE_NOPCAP=1 -DHAVE_PCAP_FILE=1 -I/usr/include/pcap -I/usr/include/python2.7 -c pcap_ex.c -o build/temp.linux-x86_64-2.7/pcap_ex.o pcap_ex.c:18:23: fatal error: pcap-int.h: No such file or directory # include <pcap-int.h> ^ compilation terminated. error: command 'gcc' failed with exit status 1 ---------------------------------------- Cleaning up... Command /usr/bin/python -c "import setuptools, tokenize;__file__='/tmp/pip-build-YH9MXT/pypcap/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-X1iDfG-record/install-record.txt --single-version-externally-managed --compile failed with error code 1 in /tmp/pip-build-YH9MXT/pypcap Traceback (most recent call last): File "/bin/pip", line 11, in <module> sys.exit(main()) File "/usr/lib/python2.7/site-packages/pip/__init__.py", line 184, in main return command.main(cmd_args) File "/usr/lib/python2.7/site-packages/pip/basecommand.py", line 161, in main text = '\n'.join(complete_log) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 24: ordinal not in range(128) [1:18:05][~]$ yum provides pcap-int.h Loaded plugins: auto-update-debuginfo, langpacks (cut) No matches found Cheers, d33tah

2 3

Is there a way to get all tor hidden service list???
by Liste 15 May '15

15 May '15

This is my TOR experiments: I was create some hidden services: Don't use standard port for SSH The server's uses a weak password in a virtual machine. Keep secret the hidden service address. Only tor can connect to the net. 2/3 server was scanned via SSL login bruteforce. What is the way to know the non publicated hidden service address? Somebody can download he HS descriptors from tor network?

2 1

Proposal 244: Use RFC5705 Key Exporting in our AUTHENTICATE calls
by Nick Mathewson 14 May '15

14 May '15

Filename: 244-use-rfc5705-for-tls-binding.txt Title: Use RFC5705 Key Exporting in our AUTHENTICATE calls Author: Nick Mathewson Created: 2015-05-14 Status: Draft 1. Proposal We use AUTHENTICATE cells to bind the connection-initiator's Tor identity to a TLS session. Our current type of authentication ("RSA-SHA256-TLSSecret", see tor-spec.txt section 4.4) does this by signing a document that includes an HMAC of client_random and server_random, using the TLS master secret as a secret key. There is a more standard way to get at this information, by using the facility defined in RFC5705. Further, it is likely to continue to work with more TLS libraries, including TLS libraries like OpenSSL 1.1 that make master secrets and session data opaque. I propose that we introduce a new authentication type, with AuthType and TYPE field to be determined, that works the same as our current "RSA-SHA256-TLSSecret" authentication, except for these fields: TYPE is a different constant string. TLSSECRETS is replaced by the output of the Exporter function in RFC5705, using as its inputs: * The label string "EXPORTER FOR TOR TLS CLIENT BINDING " + TYPE * The context value equal to the client's identity key digest. * The length 32. I propose that proposal 224's section on authenticating with ed25519 keys be amended accordingly: TYPE is a different constant string, different from the one above. TLSSECRETS is replaced by the output of the Exporter function in RFC5705, using as its inputs: * The label string "EXPORTER FOR TOR TLS CLIENT BINDING " + TYPE * The context value equal to the client's Ed25519 identity key * The length 32.

1 0

txtorcon for javascript application (npm)
by Fabio Pietrosanti (naif) - lists 14 May '15

14 May '15

Hi all, i've been considering the new way to write cross-platform desktop application using: - JS code - Chrome Engine That approach enable to re-use code across desktop, mobile, web and for the desktop the most valuable opensource project is nw.js https://github.com/nwjs/nw.js . I've been discussing on the need to integrate Tor within nw.js (that already support setting up a proxy): https://github.com/nwjs/nw.js/issues/3471 It come up with the idea/requirement that Tor ecosystem is missing a txtorcon for javascript application. A node.js compatible, npm packaged tor controller. This email to share this concern, by having a JS/npm packaged txtorcon equivalent software, would unleash the power of JS developers that are conquering the world. And future GlobaLeaks Desktop app will benefit from it, too ;) -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi

1 0

Stem Release 1.4
by Damian Johnson 13 May '15

13 May '15

Greetings wonderful carbon-based residents of the Internet. I'm pleased to announce the 1.4.0 release of Stem! What is Stem, you ask? For those who aren't familiar with it Stem is a Python library for interacting with Tor. With it you can script against your relay, descriptor data, or even write applications similar to Nyx and Vidalia. https://stem.torproject.org/ So what's new in this release? ------------------------------------------------------------------------------ Ephemeral Hidden Services and Descriptors ------------------------------------------------------------------------------ Tor's 0.2.7.1 release is bringing with it new hidden service capabilities, most notably ADD_ONION and HSFETCH. Ephemeral hidden services let you easily operate a hidden service that never touches disk... https://stem.torproject.org/tutorials/over_the_river.html#ephemeral-hidden-… This latest Tor release also brought with it the ability to retrieve a hidden service's descriptor information. Stem knows how to parse, validate, and decrypt these documents... https://stem.torproject.org/tutorials/over_the_river.html#hidden-service-de… ------------------------------------------------------------------------------ Faster Descriptor Parsing ------------------------------------------------------------------------------ When reading descriptors without validation (which is the new default), documents are now lazily parsed. This provides a very substantial speedup depending on the document's type... * Server descriptors: 27% faster * Extrainfo descriptors: 71% faster * Microdescriptors: 43% faster * Consensus: 37% faster Prefer to keep validation? No problem! Just include 'validate = True' and you'll be good to go... https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#valida… ------------------------------------------------------------------------------ As always this is just the tip of the iceberg. For a full rundown on the myriad of improvements and fixes in this release see... https://stem.torproject.org/change_log.html#version-1-4 Cheers! -Damian

1 0

Notes on Donncha's Summer of Privacy project about scaling hidden services
by Nick Mathewson 12 May '15

12 May '15

Hi! Here are some notes on Donncha O'Cearbhaill's design proposal at https://gist.github.com/DonnchaC/03ad5cd0b8ead0ae9e30 . (David asked me to write these up in time for them to be useful.) You'll probably understand what I'm saying here a lot better if you read the link above. :) In general I think this is a solid proposal. Below are a few small questions and suggestions. 1. Getting the introduction points to the management service * Synchonization, and push vs pull. I think we've started to get statistics on the average longevity of a busy introduction point. If the answer is "they change fairly often" then we should look at the expected failure rate for trying a random introduction point at any given time, given a periodic polling interval. And if *that's* high, we should look for ways to ensure that the management service learns about changes in introduction points as soon as those changes occur. One possibility here would be to have the management service keep a connection open to each of the onion services. Alternatively, the management service could have a hidden service of its own, 2. Future-proofing for proposal 224 (rend-spec-ng.txt) Stealth authorization should no longer be needed in this case; anybody who doesn't know the onion address of a prop224 hidden service won't be able to find or decrypt its descriptor. But proposal 224 does require that the onion key be cross-certified by the introduction point keys. For that to work, we will need support on the onion-service side. They won't need the master private key; only the public key. We need to make sure that as much of this as possible works with the offline-private-keys design from proposal 224 as well. Proposal 224 does not yet describe how to make the controller commands and events here work for prop-224 hidden services. We should figure out what the requirements are there at some point. 3. Introduction point collision Sometimes two different onion services might wind up picking some introduction points in common. Should we care? 4. How many introduction points to expose? It's not clear to me what the ideal number of introduction points is to put in each master service descriptor. All of them? Two from each node? All possibilities here seem to have some risks. yrs, -- Nick

2 1

txtorcon v0.13.0
by meejah 10 May '15

10 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce txtorcon 0.13.0. This adds: * support basic and stealth hidden service authorization, and parse client_keys files. * 2x speedup for TorState parsing (mostly by lazy-parsing timestamps) * can now parse ~75000 microdescriptors/second per core of 3.4GHz Xeon E3 * launch_tor now doesn't use a temporary torrc (command-line options instead) * tons of pep8 cleanups * several improvements to hidden-service configuration from sambuddhabasu1 * populate valid signals from GETINFO signals/names from sambuddhabasu1 You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.13.0 https://github.com/meejah/txtorcon/releases/tag/v0.13.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.13.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.13.0.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 3218d0fa0c22f49eee9324a5862b2d53ef77d5cb8e555e2bcffc24070aaeca7d txtorcon-0.13.0.tar.gz de266cd1b35cc2d9f4600e510d9d3a5645771d36ce36a5888a2828594feb1ef0 txtorcon-0.13.0-py2-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJVTw5SAAoJEMJgKAMSgGmn1NwIAKdBhIXgBv/0yjYHdyNxhVBp HZiluNh3sB8oRWJNuM1BY5IRuClEx05nAulKSN+ibRneHL8O7TGuAjO56HPAckn8 rtYYsUNSTjzTjGhDr4sVijLvx4lRLlzGykvMhRewB4/D/qcn9dx3vtX+7ZJ3YfSf 0/lp5XQ2n5nfHrYvfq8dUzTNmmKGx74mNQgAmQfM04Km2iWRVLMAPDZQiBCXixtF Gerkf0ybYI/lLCf/3WJOn8qCF++qQeTP49Hd2OjG8xD+Hl6dhsDBBf7lgGCLn/lw 3m+GEuBwN8TuqFogBzyChoLMkZuVe/CI2qDoHh3FsI6RJK0CqI/SOUyY0mMXdl4= =KiSA -----END PGP SIGNATURE-----

1 0