- tor-dev - lists.torproject.org

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

patch for trivial issue in onionoo
by firebrand＠ruggedinbox.com 09 May '15

09 May '15

Hi, I have recently begun to read the onionoo sources. I have submitted a small patch some time ago to fix a rather trivial issue. Could someone have a look? https://trac.torproject.org/projects/tor/ticket/15654 ** firebrand

2 1

Adding event listener for torbutton in in tor-browser
by Mohiuddin Ebna Kawsar 09 May '15

09 May '15

Hi, I'm trying to add an event listener to torbutton . at first my while initialize torbutton will send "setevents warn" through control port. and when any warning rise from OP it wil be catch by my event listener and show the warning through alert message". i'm novice in javascript. please help. Regards kawsar

1 0

Summary of meek's costs, April 2015
by David Fifield 07 May '15

07 May '15

Here's the summary of meek's CDN fees for April 2015. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 -- total by CDN $3292.25 + $3792.79 + $0.00 = $7085.04 grand total https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… The number of simultaneous users increased hugely in April, from 2000 to around 5000. There are big increases around April 9 and April 15, which I conjecture were caused by a performance improvement in meek-azure and its coverage in TWN. meek-azure used to be hugely bottlenecked, but now it should handle as many users as the others. https://lists.torproject.org/pipermail/tor-dev/2015-April/008637.html https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-april-15th-2015 We moved over 10 TB in April. Because of meek's extra layer of indirection, it doesn't correctly compute per-country user statistics (the server sees the IP address of the CDN, not of the actual user). Now that a nontrivial fraction of bridge users use meek, a nontrivial fraction of bridge users are being miscounted. Keep that in mind when you look at the per-country bridge user graphs--if users are connecting through meek, they don't count towards that country's total. Here is a ticket that aims to fix the issue by passing the client IP through the CDN. https://trac.torproject.org/projects/tor/ticket/13171 If you want to help reduce costs, you can 1. Use meek-azure; it's still covered through a grant for the next four months. 2. Set up your own App Engine or CDN account. Then you can pay for your own usage (it might even be free depending on how much you use). Here are instructions on how to set up your own: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/appengine/… https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure Then you will have to enter a bridge line manually. Follow the instructions at https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtochangethefrontd… but instead of changing the "front=" part, change the "url=" part. For example, bridge meek 0.0.2.0:1 url=https://<myappname>.appspot.com/ front=www.google.com == App Engine a.k.a. meek-google == Both bandwidth and instance hours were up about 19%. Here is how the Google costs broke down: 6304 GB $756.59 2597 instance hours $129.84 Compared to the previous month: 5316 GB $637.93 2173 instance hours $108.64 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Both usage and cost were down a bit from the previous month. Asia Pacific (Singapore) 114M requests $136.79 884 GB $117.92 Asia Pacific (Sydney) 443K requests $0.55 3 GB $0.34 Asia Pacific (Tokyo) 51M requests $61.03 305 GB $39.32 EU (Ireland) 173M requests $208.17 1598 GB $127.21 South America (Sao Paulo) 5M requests $9.91 23 GB $5.31 US East (Northern Virginia) 46M requests $45.56 418 GB $33.26 -- total 389M requests $462.01 3231 GB $323.36 https://globe.torproject.org/#/bridge/3FD131B74D9A96190B1EE5D31E91757FADA1A… == Azure a.k.a. meek-azure == meek-azure increased a lot because of improved performance this month. https://onionoo.torproject.org/bandwidth?fingerprint=AA033EEB61601B2B7312D8… Estimated bandwidth use this month: 2015-04 1982 GB Compared to last month: 2015-03 737 GB https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… David Fifield Earlier reports in this series: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html https://lists.torproject.org/pipermail/tor-dev/2015-February/008235.html https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html https://lists.torproject.org/pipermail/tor-dev/2015-April/008596.html

6 14

exitmap feature requests?
by nusenu 07 May '15

07 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Philipp, do you consider feature requests via [1] or would you recommend forking and implementing it oneself? thanks, nusenu [1] https://github.com/NullHypothesis/exitmap/issues -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVSlpSAAoJEFv7XvVCELh0lCQQALCIDN+o7o5rubDUP7+O2J01 pI1ezUWqRk1BkKXYOPhB17gJke/5XzYCQkA/VW8FLmjf52WnucFg25c7TJ6hbRFd T73jfQvIAoNm938c/ZRHND8xOCOxaO4oa+sd5+oPNDYCfEg3gHfFxHtjgdvUzF+P Y2CqbO271drrFzkWk0ILSoRJihmZjSZHJl21gvfmeDKRsyycig/yKip/Lyq9n8QF O9rneAsVXtT72uCKnjd7rAqVwetTgqiNKQMrOG4hZ61BoGgrwYueWpTVN9wSNNOO 755TnSjZw+/rjYJxIQngbhdFSeFOX2MvE2gaUsut4b1tUa23QSQ5bLhPVEw4P6u2 Hm9lo06RCPNoYe16Hr+ff2rLMK/UU2LfoYkBZk2f0FM7LcYzEOXs6mmeUREBoJw8 V6m+O1orczjwppF9aPBLXihUr8FZQyuhIYMPpwYnMdrtysiFAKvOusOxr7svmM/w nQvPrEy3SuiyyoQa8VGZt0DejeUfyXwhkndbTC/goxKf44pWGDVUB15fyUIKh17l 9vNVdMbCmmRVHa8Mto3RmjlNRG9c3gqsmaMteAJohXGAbe8qoSMqmRF095HYjlhb MD5UPiuNIoAqOBjC2FMTYnLT2bmrRmcQD0i0dUEtK6wg5w11M3pSbk+jR/7AD5uZ gPjSfXUM718ly0avzegm =+LN2 -----END PGP SIGNATURE-----

2 1

Tor + Apache Traffic Server w/ SOCKS - works now!
by CJ Ess 05 May '15

05 May '15

So I've been looking for a long time for something modern to sit between my browser and Tor -- something modern, capable, and efficient (i.e. doesn't fork every connection). Years ago Yahoo got some proxy software from an acquisition, a few years later they made it open source as Apache Traffic Server ( http://trafficserver.apache.org/) and today its the backbone of Yahoo's infrastructure. They have a number of full time engineers that work on it full time, they use it in production, and they are implementing cutting edge features like IPv6, SPDY, and HTTP/2 support. SOCKS is was one of the legacy features of Apache Traffic Server. However, it hasn't been maintained. If you build from git right now you'll find SOCKS support completely broken at least four ways (a couple bad asserts, wrong byte order, and an uninitialized field). They took the documentation on the SOCKS feature out a while ago but never got around to removing the code. Since it was there I spent some time over the weekend and fixed it. There are still some issues around SOCKS still but it works well enough that you can surf though tor with it. If there is interest in it here I'd be happy to put together a how-to for Linux and MacOS to get it built and configured. I'd also like to encourage people to make some noise - Yahoo does have SOCKS servers internally but they don't test using Traffic Server with them because they don't think anyone uses the feature (and they are right, there is no way the code works for anyone in the present state). But if there was interest then maybe they'd keep the code fresh going forward. I'm including a copy of the patch with this e-mail just to get it out. You can pull their git repository (https://github.com/apache/trafficserver) and apply it to the master master branch.

3 3

Re: [tor-dev] working back to socks_request_t
by teor 05 May '15

05 May '15

> Date: Mon, 4 May 2015 16:07:20 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > Thanks for going into so much detail, you've given me a lot to think about. > The real solution is probably the one that nobody wants to take on - having > an application HTTP port that could take direct input from HTTP aware stuff > and utilize a richer set of information then SOCKS allows for. I've spent a > couple evenings looking to see if I could take the code stuff from the > dirport and use it for that purpose. I need to spend another couple > evenings and and go back and look at the SOCKS4 stuff, I've just recently > realized that the state machine for that is closer to an http > request/response. CJ, Pluggable transports are designed to arbitrarily change how tor makes outgoing connections. The existing transports are used for obfuscation, but they could be used for dynamic proxy authentication as well. (Some do take authentication arguments.) You'd just have to work out which user to authenticate each tor connection with - which is a difficult question of policy. This arises because tor only makes a small number of long-term connections to a few guard nodes, and multiplexes multiple streams over these connections. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-dev] working back to socks_request_t
by teor 04 May '15

04 May '15

> Date: Sun, 3 May 2015 12:34:51 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > On Sun, May 3, 2015 at 11:06 AM, teor <teor2345(a)gmail.com> wrote: > >>> Date: Sun, 3 May 2015 02:50:46 -0400 >>> From: CJ Ess <zxcvbn4038(a)gmail.com> >>> >>> So I'm doing a bit of an experiment, the idea being that if you have a >>> group of tor users sharing common infrastructure then its a slightly >>> different situation then one lone user, and you wantto emphasize that >>> resources should not be shared, caching should be minimal and >>> non-persistent, you need to keep usage from standing out, etc. … >>> So plan B is everyone involved runs their socks speaking browser on their >>> desktop/laptop, everyone runs a tor client on the same device as their >>> browser, we use the HTTPProxy/HTTPSProxy feature of the clients to navigate >>> the firewall, everyone uses their own credentials instead of having one ID >>> draw attention for high utilization, and the presence of >>> the Proxy-Authorization header takes care of any caching/session sharing >>> issues along the way. >>> >>> To make that work, the one question I have for tor-dev is if its possible >>> Here: >>> >>> https://github.com/torproject/tor/blob/24f170a11f59e26dec3a24d076b749c8acc7… >>> >>> To work back to the socks_req, so that I can pass through the username and >>> password to the upstream proxy instead of the one global username/password? >> >> Hi CJ, >> >> It sounds like you're looking for one of the HTTP(S)ProxyAuthenticator >> options - you can configure a different username and password in the torrc >> file on each client's desktop/laptop. >> >> … >> >> If these options aren't what you're looking for, can you explain what you >> want done with the SOCKS request in a bit more detail? > > So underlying idea in this case is to pass thru the proxy credentials from > the browser, so they don't have to be had coded in plain text in the tor > config - you exit the browser and the credential goes away (or maybe its > encrypted in the browser password manager), if you change your password you > don't have to go update the tor config and bounce it, if its a shared > device you don't have to reconfigure and possibly leave your credentials > around, etc. > > That sounds good conceptually, but to implement I somehow need to work back > from the connection_t passed into the function I mentioned to something > that has the socks info (circuit? associated edge connection?) I tried to > trace it though and nothing jumped out at me but maybe there is some type > casting happening and I'm missing it. The other option would be to pass the > info down through extra arguments or copied into extra field members. > Either way I'm speculating there might be a really simple way to do this > and worth the time writing up the question. If I get it working I'd be > happy to send in a patch to the this list. Hi CJ, There isn't a one-to-one correspondence between web browser SOCKS connections and Tor connections: 1. Each SOCKS connection results in a stream, and tor multiplexes multiple streams over multiple circuits through the same connection to the first hop in the path. 2. tor also initiates streams, such as directory fetches, without any corresponding SOCKS connection from the browser. 3. tor pre-emptively launches circuits, then uses them for client connections once a SOCKS request is received. 4. tor sometimes cannibalizes existing circuits by adding a hop to them. tor makes a connection to 1-3 guard nodes, and those connections carry the majority of the web browser SOCKS traffic. They are authenticated at tor launch, before any browser makes a request, and I'm pretty sure that's it for authentication from then on. If you could get authentication passthrough working, you'd still run into the following compatibility issues: 5. Tor Browser uses the input SOCKS username (I think) to manage stream-based isolation for different tabs, based on the URL. This would prevent you using Tor Browser with your modified version of tor, leaving you with a browser with fewer anonymity protections. 6. Some pluggable transports use the output proxy username to pass arguments. This would prevent you using pluggable transports with your modified version of tor. And the following anonymity / usage issues: 7. If each SOCKS connection has a corresponding circuit, and you identify the user who initiated the circuit, you make it easier to de-anonymise the user behind the circuit. 8. Given that tor can multiplex multiple users over each circuit, who is responsible for bandwidth over-use? If you're still keen on continuing, the closest that the socks authentication details get to where you need them is in conn->socks_request in circuit_get_open_circ_or_launch(). The call stack from then on is: circuit_launch_by_extend_info() circuit_establish_circuit() circuit_handle_first_hop() channel_connect_for_circuit() channel_connect() channel_tls_connect() connection_or_connect() Which initialises the or_connection_t struct "conn", then makes the connection to the proxy (if set). You could add the username and password to the conn data structure here. When the connection has finished connecting, the callback is: connection_or_finished_connecting() Which calls: connection_proxy_connect() Which could then use the username and password from the conn data structure, if they exist - otherwise, it could use the default set in the config. I still think you'll get the default authentication most of the time, because of tor's pre-emptive guard connections. When you reply, can you avoid top-posting? Some mail clients top-post by default. But it's easier to follow the conversation if replies come after the initial email. Feel free to reply in the middle of the email as well. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

Re: [tor-dev] design for a Tor router without anonymity compromises
by teor 04 May '15

04 May '15

> Date: Sun, 3 May 2015 16:23:08 -0700 > From: coderman <coderman(a)gmail.com> > >> I suggest also adding mandatory audit logging to the scope of the >> router software. In my opinion any and all state changes, whether >> automatic (Tor circuit change) or manual (administrator changing >> configuration) must be logged. > > this is an important detail; thank you for bringing it up. i will add > the expected run logging and troubleshooting logging output collected > on device and available to the owner via privacy director > administrative access. Some users will want as little logging as possible, as it can lead to privacy leaks if the device is compromised - may I suggest you turn it off by default? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

Damian's Status Report - April 2015
by Damian Johnson 04 May '15

04 May '15

Hi all! My April was split between SoP prep and Nyx. Changes for the later unfortunately aren't yet ready so this is gonna be a shorter status report than usual. -------------------------------------------------------------------------------- Tor Summer of Privacy -------------------------------------------------------------------------------- It's a thing! Of our twenty-two applicants sadly we only had funding for four, but all have great projects and we look forward to working with them this summer! https://blog.torproject.org/blog/tor-summer-privacy-projects Personally I'm particularly excited since this will be the first time I've mentored since 2012. Cristobal's working on a web dashboard for relay operators - think nyx, but ajax... https://leivaburto.github.io/sop-proposal/ -------------------------------------------------------------------------------- Few other noteworthy things were... * Built on David's hidden service descriptor work by adding a get_hidden_service_descriptor() method to Stem. Next up is support for Yawning's ephemeral hidden services... * Sambuddha revised Stem's Twitter example to support Twitter's v2 API. (#9003) * Stem test for installation via our setup.py. (#15258) Cheers! -Damian

1 0

Re: [tor-dev] working back to socks_request_t
by teor 03 May '15

03 May '15

> Date: Sun, 3 May 2015 02:50:46 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > So I'm doing a bit of an experiment, the idea being that if you have a > group of tor users sharing common infrastructure then its a slightly > different situation then one lone user, and you wantto emphasize that > resources should not be shared, caching should be minimal and > non-persistent, you need to keep usage from standing out, etc. The problem > with my original idea is that everything that does HTTP <> SOCKS is one or > two decades old, and draws a lot of attention because it forks for every > connection or is some strange process that nobody has ever seen before. > > So plan B is everyone involved runs their socks speaking browser on their > desktop/laptop, everyone runs a tor client on the same device as their > browser, we use the HTTPProxy/HTTPSProxy feature of the clients to navigate > the firewall, everyone uses their own credentials instead of having one ID > draw attention for high utilization, and the presence of > the Proxy-Authorization header takes care of any caching/session sharing > issues along the way. > > To make that work, the one question I have for tor-dev is if its possible > Here: > > https://github.com/torproject/tor/blob/24f170a11f59e26dec3a24d076b749c8acc7… > > To work back to the socks_req, so that I can pass through the username and > password to the upstream proxy instead of the one global username/password? Hi CJ, It sounds like you're looking for one of the HTTP(S)ProxyAuthenticator options - you can configure a different username and password in the torrc file on each client's desktop/laptop. If you are going to run a SOCKS-speaking browser, why not run the Tor Browser? It does a lot more to protect your anonymity than most. From the tor manual page: HTTPProxyAuthenticator username:password If defined, Tor will use this username:password for Basic HTTP proxy authentication, as in RFC 2617. This is currently the only form of HTTP proxy authentication that Tor supports; feel free to submit a patch if you want it to support others. HTTPSProxyAuthenticator username:password If defined, Tor will use this username:password for Basic HTTPS proxy authentication, as in RFC 2617. This is currently the only form of HTTPS proxy authentication that Tor supports; feel free to submit a patch if you want it to support others. If these options aren't what you're looking for, can you explain what you want done with the SOCKS request in a bit more detail? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

working back to socks_request_t
by CJ Ess 03 May '15

03 May '15

So I'm doing a bit of an experiment, the idea being that if you have a group of tor users sharing common infrastructure then its a slightly different situation then one lone user, and you wantto emphasize that resources should not be shared, caching should be minimal and non-persistent, you need to keep usage from standing out, etc. The problem with my original idea is that everything that does HTTP <> SOCKS is one or two decades old, and draws a lot of attention because it forks for every connection or is some strange process that nobody has ever seen before. So plan B is everyone involved runs their socks speaking browser on their desktop/laptop, everyone runs a tor client on the same device as their browser, we use the HTTPProxy/HTTPSProxy feature of the clients to navigate the firewall, everyone uses their own credentials instead of having one ID draw attention for high utilization, and the presence of the Proxy-Authorization header takes care of any caching/session sharing issues along the way. To make that work, the one question I have for tor-dev is if its possible Here: https://github.com/torproject/tor/blob/24f170a11f59e26dec3a24d076b749c8acc7… To work back to the socks_req, so that I can pass through the username and password to the upstream proxy instead of the one global username/password?

1 0

onionoo: historic details.json data
by Nusenu 02 May '15

02 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Karsten, can one download historic onionoo documents (details.json) archived somewhere or would one have to setup onionoo + feed old data into it to achieve that? thanks, Nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVIaqIAAoJEFv7XvVCELh0OQgP/3FiBM3uMifPW9A0u8sMuh1E 7iFDmU52MNmkeToBUnuxuUK+7ig96tz/p5Ds6OyaAtC0Ld/IzRlIU5ELjqDwRqMD LPaafWm21QHO8y4fgW5FfGDfFTeLL/b3Lm1E9VmJ8wpOsgpzNnBMUoeDrpDyE3Ow zHXM/IfCSROqmO9lOeU6YGQTwInucc0HSveAWQ9i/x6iks9kMguzGnuWTxgfwA61 RQT4KUKZI+b5w//8V3/IpR5jlQ2N4OJrURpVhaKKNYMy+mqOfl5/a1ZPyQhhDaxj eLfg0qQmsk9IJY/6dZa0XogsmAzRCcEO/Ha0b0ZoiWs+VFo97cczoWdVWHoKpsyS X/qeehkOS13l22mw8va+yuj4zoRBrgK2chzcG2iPgVBeTu1H7B+x57PQrQXaCdaf rq8wwlS7mgaMQ6mgHyOQ1niZDTnvJaY0e3gVsgucR7YOTdALxnnHhQkyNboCWq/E 180SetWZfIHbL3cV38DRxYKzijwSu1gqmkwTJWffylb5SMja1TdW9cCq/RzidqyF v7vLXHQwmrRQ0XOy9UULe5XtU0Fe4YCm/zMNzBHHGIrePd664mYKqqXP2dlempwb BbbVgMLuFC2sy2eqxtwyQrrDUoWrEovUxg/BeoKO8RYXzNhPtha8eQkAhexhNux2 2mosesv/fooaQnt17qAo =q6LM -----END PGP SIGNATURE-----

6 16

#14995: systemd unit files - review
by Nusenu 02 May '15

02 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi weasel, following your comment [1] about your plans to use systemd instead of init.d scripts I prepared unit files [2] - tested with debian jessie. Would be great if you could comment on them. Since it feels a bit as if I would use the wrong communication channel (trac), please let me know if I should move this elsewhere. thanks, Nusenu [1] https://trac.torproject.org/projects/tor/ticket/14995#comment:14 [2] https://trac.torproject.org/projects/tor/ticket/14995#comment:24 https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian… https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian… -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVFqosAAoJEFv7XvVCELh0AjgQAIlLflC6f+mqUUiAyvQsTO/4 +fNK1MBFUNJUpEws3gqD/3OQfBnhuV9Po4SiRMPfQo0IHuLSB0jNHslOexVBWzpY s4ypeNAH+Eu58Pomexo9xOMCZTmM7Jmhm8HdCodSXBMSKlK1jMwqqmRRQDnijf3T hYos6yeJydwXnV2yDaeF6AOiuAzIQC2s+Mwu+tynX3ETCIyDzsDcQEOaDiwnmWBX 76kIqz0sF0N7tOeMiLoMvK1J9HhW+sMH4aaGwZFXPCMLEpziIB5spEmgvpa+SoQ0 dG2q3Hd7ryBaac/KSeX/Dyidur8LxheA9slVqwkdcorXWBdQd7Xnom2WTOs/2cSf Dy3ZFJD1vi3/y6Gq0DsWY3Z4XhPPs4gTVOL056Xc/GyZXmPvAVI5mk8EdtU7ezbu NxXqjVoEcX59IWhyMOjh2eaeEZvaxmyfP38ek2f6nH5pZv9FtmjKZ61LwYtL8qJx wEn+qIVXy1Zl+qU/NhUpMeUqn029Ci+mL+6x/JfNpaka81Rtqsb+6SKQQwPwGGu7 2SwsDjM+B6YsWSf3niL3rp23XWaT1mM830QBnTrMpE+kht/4b1ytgs7NV72E30+5 Ibi5y/F/TkTc6yExJd1qxKkpXY0gnEWIgf0l4ik5FOD3DK47lQgKYg4feAcPxLUo qFDT5Y0Fnhezh5DVnRp+ =mtYl -----END PGP SIGNATURE-----

3 5

Released BridgeDB-0.3.2
by isis 02 May '15

02 May '15

Hello all, Yesterday I released and deployed BridgeDB-0.3.2, which has several major fixes and changes. Major changes visible to users include: changing the default pluggable transport to obfs4, and users requesting bridges will note that they are again normally receiving the maximum number (3) of bridges. The temporary decrease in bridges was due to the fact that, while rewriting BridgeDB's bridge descriptor parsers (#9380), I implemented full verification of all cryptographic data involved, including signatures and descriptor digests, in order to validate the chain of bridge information from the networkstatus document (produced by the BridgeAuthority), to bridge server-descriptors, and finally to bridge `extrainfo` descriptors (which contain information on a bridge's pluggable transports). This turned out to be somewhat of a bad idea, because the BridgeAuthority appears to not producing good networkstatus documents (see #11216, #12254, #15707, and #15866). Changes in version 0.3.2 - 2015-05-01 * FIXES a problem with the calculation of Levenshtein distances between blacklisted email addresses and those on incoming email. This fixes a problem with the fuzzy matching implemented in #9385: https://bugs.torproject.org/9385. * FIXES #1839 https://bugs.torproject.org/1839 BridgeDB's distributors now rotate their hashrings at configurable scheduled intervals. * FIXES #4771 https://bugs.torproject.org/4771 BridgeDB now records which of the HTTPS Distributor's sub-hashrings are used for clients coming from Tor Exit nodes and other known proxies. * FIXES #12504 https://bugs.torproject.org/12504 Which Pluggable Transports BridgeDB distributes is now easily configurable via the bridgedb.conf configuration file. * FIXES #13202 https://bugs.torproject.org/13202 Old bridges running Tor-0.2.4.x with Pluggable Transports like scramblesuit and obfs4proxy have a bug which causes them to not include the PT arguments in the `transport` line they submit to the BridgeAuthority in their extrainfo descriptors. This causes BridgeDB to have broken bridge lines for these bridges. For example, scramblesuit requires a `password=` in the `ClientTransportPlugin` for clients to connect to it. If BridgeDB receives a line in that bridge's extrainfo which says `transport scramblesuit 1.2.3.4:1234` (without a password), then when BridgeDB gives clients a bridge line for that bridge, it'll look like "Bridge scramblesuit 1.2.3.4:1234" - meaning that it won't work. This fixes the issue by excluding broken transports from being distributed to clients. * FIXES #15517 https://bugs.torproject.org/15517 For all clients who are coming from IPv6 addresses and are not using Tor, who go to https://bridges.torproject.org, BridgeDB now groups these clients together by /32. This "grouping" causes all IPv6 clients within the same IPv6 /32 to get the same bridges. Previously, BridgeDB grouped IPv6 clients by /64 (which is ridiculously small, considering standard IPv6 allocation sizes). For all clients who are coming from IPv4 addresses and are not using Tor, BridgeDB now groups these clients together by /16. Previously, BridgeDB grouped IPv4 clients by /24. (This latter change was technically made as part of #4771.) * FIXES #15464 https://bugs.torproject.org/15464 The setup procedure for creating a BridgeDB Continuous Integration build machine is now simplified and generalised to include build environments like Jenkins, not just TravisCI. * FIXES #15866 https://bugs.torproject.org/15866 BridgeDB now ignores nearly all the information in the networkstatus-bridges file created by the BridgeAuthority. * ADDS benchmark tests to BridgeDB's test suite, and some of BridgeDB's algorithms have been revised to improve their speed. As per usual, the full CHANGELOG is available here: https://gitweb.torproject.org/bridgedb.git/tree/CHANGELOG -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

what capabilities does tor need for reloading?
by Nusenu 29 Apr '15

29 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, 'systemctl reload tor' fails due to hardening restrictions in tor's systemd service file [1]: CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE Removing that line "solves" the reload issue. Reloading with that line does not generate any tor debug loglines. What capability would one have to add to the list to make it work with CapabilityBoundingSet? thanks, Nusenu testing with: tor 0.2.6.4, jessie/systemd 215 [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n26 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCVA7AAoJEFv7XvVCELh0bWIQAKfDZdhwrcWzwOHEP/o3FMoa BTkMxjHdEDezlaHd61/XWHC1cYNOi6kqe/xGL1HRMtDwl09tbn3lq0Vty9P9hBP5 ucLaS1Izz0w7VprEd4ZK+/G4pV8Ht6Kjd7LSaV8RsjdCfK9g5WaI/IDIVGbYKUnC NVJxY+XCxZsvMmkfCUo1un6yZ/p0eQEfksDwtDvf7EupIy3o5wYJhM1bcvVzm/3H UenP8t8VBb7TVOBRuZUyMzS173db/SKp2tY1IOiUktzyJqzzck8gPJvQ4l8DoeqM E2yVr+Qvex/IXRx379sJTyBJt9xthC9BS91uUJA0G3dbYVSvRoUN5XDjaqYztSN3 ctkjT3cocLDu43EslGo/Egh+xWTMdnTvcaTIoLkD5IN4FWu3IrjWnG0gOOyNyPf5 F4UfCty5xn9ztb0y7Zf2GOliR9CnkSB8PIuMt4ManvrMGOwYPZw1KsGsc49UYadn XhEUj1uzf3FBZw2LmbiBR5lNGX2WanWt83EwkiH03MsBkouD60+D/RJ5UQ8pVEwm JHLBqbT2GtBCda3OIPec1kdh3P5TFF+aN9aC1HkVsYRwoUJtIjxPg3wkrOVCU4VF ZJVbqlVuJQn8/3GnphkQgt+jJqTl3b4Ttksu+omGJgYU2Wu42VNFvCFraeQ75q4J D1NinH/G/3I3KBYP+JNu =/eJ6 -----END PGP SIGNATURE-----

3 6

Re: [tor-dev] shipping with fallbackdir sources
by teor 28 Apr '15

28 Apr '15

> > Date: Fri, 17 Apr 2015 18:56:01 +0200 > From: Peter Palfrader <weasel(a)torproject.org> > > Hi, > > so, Tor has included a feature to fetch the initial consensus from nodes > other than the authorities for a while now. We just haven't shipped a > list of alternate locations for clients to go to yet. > > Reasons why we might want to ship tor with a list of additional places > where clients can find the consensus is that it makes authority > reachability and BW less important. > > At the last Tor dev meeting we came up with a list of arbitrary > requirements that nodes should meet to be included in this list. > > We want them to have been around and using their current key, address, > and port for a while now (120 days), and have been running, a guard, and > a v2 directory mirror for most of that time. > > I have written a script to come up with a list of notes that match our > criteria. It's currently at > https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates > > It currently produces > https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list > > Discuss :) Peter, your list only includes the IPv4 addresses of the directories. Can you include the IPv6 addresses as well, like: https://trac.torproject.org/projects/tor/ticket/8374#comment:8 If we can get a list we're happy with, I propose we distribute them in a similar fashion to the geoip file, a flat file provided with the distribution. This would require a torrc option for the location of the file. (I don't think signing the file has a specific threat model: the list of directory authorities themselves could almost as easily be modified in the code before a build.) Do we need to contact the operator of each directory mirror for permission? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0