- tor-dev - lists.torproject.org

generate relay fingerprint without tor given the datadir/keys folder?
by nusenu 04 Feb '17

04 Feb '17

Hi, given the files within the datadir/keys folder (without the datadir/fingerprint file), is there an easy way to generate the relay fingerprint? (using openssl?) According to the spec [1] the fingerprint is the SHA1 hash of the public key. (I assume RSA pubkey) According to the tor man page [2] the RSA public key should be in keys/secret_id_key. openssl rsa -in secret_id_key -pubout| ..? |sha1sum thanks, nusenu [1] > "fingerprint" fingerprint NL > > [At most once] > > A fingerprint (a HASH_LEN-byte of asn1 encoded public key, encoded in > hex, with a single space after every 4 characters) for this router's > identity key. A descriptor is considered invalid (and MUST be > rejected) if the fingerprint line does not match the public key. [2] > DataDirectory/keys/secret_id_key > A relay’s RSA1024 permanent identity key, including private and > public components. Used to sign router descriptors, and to sign > other keys.

2 4

onionoo: understanding 'exit_policy_v6_summary'
by nusenu 01 Feb '17

01 Feb '17

Hi Karsten, given this torrc configuration and exit policy: https://lists.torproject.org/pipermail/tor-relays/2017-January/011806.html would you expect onionoo's 'exit_policy_v6_summary' to be not set? [1] https://onionoo.torproject.org/protocol.html#details writes: > Missing if the relay rejects all connections to IPv6 addresses. thanks, nusenu [1] https://atlas.torproject.org/#details/5E762A58B1F7FF92E791A1EA4F18695CAC667… {"nickname":"sorrentini","fingerprint":"5E762A58B1F7FF92E791A1EA4F18695CAC6677CE","or_addresses":["128.199.76.145:443","[2400:6180:0:d0::18a7:d001]:443"],"last_seen":"2017-01-27 13:00:00","last_changed_address_or_port":"2017-01-11 09:00:00","first_seen":"2016-11-30 03:00:00","running":true,"flags":["Exit","Fast","Running","Stable","Valid"],"country":"sg","country_name":"Singapore","region_name":"Central Singapore Community Development Council","city_name":"Singapore","latitude":1.2855,"longitude":103.8565,"as_number":"AS133165","as_name":"Digital Ocean, Inc.","consensus_weight":420,"host_name":"128.199.76.145","last_restarted":"2017-01-21 03:29:31","bandwidth_rate":1073741824,"bandwidth_burst":1073741824,"observed_bandwidth":1225379,"advertised_bandwidth":1225379,"exit_policy":["reject 0.0.0.0/8:*","reject 169.254.0.0/16:*","reject 127.0.0.0/8:*","reject 192.168.0.0/16:*","reject 10.0.0.0/8:*","reject 172.16.0.0/12:*","reject 128.199.76.145:*","accept *:53","accept *:80","accept *:110","accept *:143","accept *:220","accept *:443","accept *:873","accept *:989-990","accept *:991","accept *:992","accept *:993","accept *:995","accept *:1194","accept *:1293","accept *:3690","accept *:4321","accept *:5222-5223","accept *:5228","accept *:9418","accept *:11371","accept *:64738","reject *:*"],"exit_policy_summary":{"accept":["53","80","110","143","220","443","873","989-993","995","1194","1293","3690","4321","5222-5223","5228","9418","11371","64738"]},"contact":"0x44BB1BA79F6C6333 <tor-admin AT zumbi dot com dot ar>","platform":"Tor 0.2.9.8 on Linux","effective_family":["$82C92FBAF2196EC346670D12BB9650FE9FF55741","$EFD2EEB91E5C5D8CB999B1EC68D89E51F8776AC7"],"consensus_weight_fraction":8.568019E-6,"guard_probability":0.0,"middle_probability":0.0,"exit_probability":3.799685E-5,"recommended_version":true,"measured":true}

3 5

[RFC] Directory structure of prop224 onion services
by George Kadianakis 01 Feb '17

01 Feb '17

Hey list, with service-side prop224 implementation moving forward, we need to pin down the directory structure of prop224 onion services. This will be very similar to the current directory structure, but with some mods to facilitate assymetric client authorization keys and offline keys. As people have pointed out, the HS directory structure matters less after the introduction of ephemeral ADD_ONION onion services, but still it's an important part of onion service sysadmin UX. So the HiddenServiceDir directory will contain the following items: - "./hostname" [FILE] This is a file containing the onion address of the onion service. As you can see it's the same filename as in v2. Should we suffix it with v3 to make it clear that it's v3 onion? Would we ever have v2 and v3 onions living in the same directory? - "./private_key_ed25519" [FILE] This is the file containing the private master ed25519 key of the onion service. If offline keys are _enabled_, then this file doesn't exist and instead a directory is made containing blinded keys for every day [TODO: The directory format here will be specified in the future]. - "./client_authorized_pubkeys" [FILE] If client authorization is _enabled_, this is a newline-separated file of "<client name> <pubkey>" entries for authorized clients. You can think of it as the ~/.ssh/authorized_keys of onion services. - "./client_authorized_privkeys/" [DIRECTORY] "./client_authorized_privkeys/alice" [FILE] "./client_authorized_privkeys/bob" [FILE] "./client_authorized_privkeys/charlie" [FILE] If client authorization is _enabled_ _AND_ if the hidden service is responsible for generating and distributing private keys for its clients, then this directory contains files with client's private keys. The idea is that these files can be shredded and deleted after the private key has been passed to the client. For more context here, please read the client authorization thread in [tor-dev] and see 'Appendix F' of prop224 for more details on how this works. So this is it. The above should handle most uses of onion services + client authorization. The directory format of offline keys will be specified as we move forward with implementation. Hope things here are not too controversial. Looking forward to your feedback. In a few days, I will add a small Appendix section to prop224 with the above, and also fix the parts of 'Appendix F' that got outdated since then. Cheers!

6 12

Re: [tor-dev] GAEuploader
by Katherine Li 01 Feb '17

01 Feb '17

Hi Tim, Thank you for your insightful questions! My responses are below: *> Is this the cheapest zone/region for computation or bandwidth? If I am not in the US, would it be faster or cheaper for me to use a local google data center?* Yes, it would be faster for you to use a local google data center <https://cloud.google.com/appengine/docs/locations>. I have added a variable "REGION" in the script of the uploader. You can now change the region by replacing "us-central" with another region. I have also added an explanation of how to do this in the README. Below is a list of all the regions: REGION SUPPORTS STANDARD SUPPORTS FLEXIBLE asia-northeast1 YES YES europe-west YES NO us-central YES YES us-east1 YES YES You can also obtain this list via the following terminal command <https://cloud.google.com/sdk/gcloud/reference/app/regions/list>(with GAEuploader as your current directory): ./google-cloud-sdk/bin/gcloud app regions list As you pointed out, I have set the zone to zone3 in my original code. However, it turned out that zone is relevant only when working with Google Compute Engine <https://cloud.google.com/compute/>, which is not the case for GAEuploader. So I have removed the line "subprocess.check_call([" ./google-cloud-sdk/bin/gcloud", "beta", "config", "set", "compute/zone", " zone3"]) *> Which tor bridge does the traffic for these instances go through? (Or does this set up a tor bridge as well?)* The bridge uses https://meek.bamsoftware.com/, which is on the same host as the meek-azure bridge, but not rate-limited like meek-azure is. You can find more information on Tor relays at its Atlas page: https://atlas.torproject.org/#details/C20658946DD706A7A2181159A1A04C D838570D04 If you want to use a different bridge, you can edit the file appengine/reflect.go before running uploader: forwardURL = "https://meek.bamsoftware.com/" Thanks again for your input! Please let me know if you have any more questions/feedback. Best, Katherine Li

2 1

git-update: transparently torified git pulls
by carlo von lynX 31 Jan '17

31 Jan '17

Hi, here it is. Style may be crude as I usually write perl. #!/bin/sh # # A variant of git pull which operates over Tor and # - figures out when 'torify' needs to be used # - shows the changes that were made to the repository # - before attempting to merge # --lynX & heldensaga, 2017 # # I recommend piping the output into # vim -R "+set syntax=diff" # but since that isn't everybody's choice of editor # I won't work it into this script... # would be more elegant to tell you how to # configure this in your .git/config? gitdiff="git diff -b -M77% --minimal" # 'resolve' has served me well as default strategy gitmerge="git merge -s resolve" branch="$*" if test x"$*" = x; then branch="origin" fi # echo $branch url=`git remote get-url $branch` if test x"$url" = x; then exit fi # echo $url case $url in http*) torify="" echo "*** Fetching from $url via web proxy" ;; *) torify="torsocks" echo "*** Fetching from $url via torsocks" esac # echo $torify $torify git fetch $branch \ && $gitdiff master..$branch/master \ && exec $gitmerge $branch/master

2 2

ExitPortStatistics interpretation
by nusenu 30 Jan '17

30 Jan '17

Hi, I'm looking at ExitPortStatistics. Since the spec [1] is not very specific, I wanted to confirm that my assumption is correct: The current tor implementation includes the 10 most relevant ports, correct? (highest number of bytes or stream) example: exit-streams-opened 80=5178868,182=1092,443=3499276,5000=29600,5753=8920,6881=43496,8080=31184,8333=472,8999=16572,51413=51496,other=1925104 so the ports 80 182 443 5000 5753 6881 8080 8333 8999 51413 are the most used exit ports on that given relay (not by that order). thanks, nusenu [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1082: > "exit-kibibytes-written" port=N,port=N,... NL > [At most once.] > "exit-kibibytes-read" port=N,port=N,... NL > [At most once.] > > List of mappings from ports to the number of kibibytes that the > relay has written to or read from exit connections to that port, > rounded up to the next full kibibyte. Relays may limit the > number of listed ports and subsume any remaining kibibytes under > port "other". > > "exit-streams-opened" port=N,port=N,... NL > [At most once.] > > List of mappings from ports to the number of opened exit streams > to that port, rounded up to the nearest multiple of 4. Relays may > limit the number of listed ports and subsume any remaining opened > streams under port "other".

2 5

[release] Onionoo 3.2-1.1.0
by iwakeh 30 Jan '17

30 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! Another release of Onionoo is now available here: https://dist.torproject.org/onionoo/3.2-1.1.0/ Besides some technical improvements that are listed in the changelog [0] this release contains a protocol extensions [1]: * Extended order parameter to "first_seen" and added response meta data fields that facilitate paging access to Oninoo data (see [2] for details). * A bug was fixed, that prevents noting bridges as first seen on January 1, 1970 when in fact they were never mentioned in a bridge network status and only learned about from their self-published bridge server descriptors (see ticket [3]). * The data on the main Onionoo instance [4] was cleaned to not report the wrong first_seen dates anymore. Please direct comments and questions to the metrics-team mailing list [5]. Cheers, iwakeh [0] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md?id=5b219203b87… [1] https://onionoo.torproject.org/protocol.org [2] https://onionoo.torproject.org/protocol.html#responses [3] https://trac.torproject.org/projects/tor/ticket/20994 [4] https://onionoo.torproject.org [5] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYjv3nAAoJEPeEx9Sa/gviBU0P/j/ABxgGW7w46SHALGqJWazC /0bF3OipaNQc8UXwejwh7GGH9IZJxk1W5IUMrf9Fu7USTrcmCmhZowBPNbh6vc64 QnFtOPgDbm/S7lURhLr56UIb68zpbbtCQu3++mj2r4oep3g3avKOcIFyNYsLnM8z qGhLRIhSyJtHC0ZLojzDgRzT3gD4qKiU79rofJysaevoHRzusSDlHB7m/LBLcGz3 NFBemfB3NtAWJcl8G50hileMp2uLnepZ5eyfWV1PmNvT3j96x4L7sUwVywdKHzjs P31R7ysgT3oYf2lcwsyCAZLrBF+ZklVOGivHcxTByVJf7At4N/j86V5iSr0I7H4n 3KKdIjzFjwYLN8E9LUeqiD+v4+a4Z+tJO56XV2O0P4r3szMaSxVK13XNriHlEp6A 3rKvyJDpGS40Kijna0H5E7NdHS6za1S2Pj/DJr62WFft/6lz48cm6HdzS7IQTRGP zHYuYcT5tMn1jS72PQmIJd8x7hP8C0G18lp9vs6au/S4rfw+/XXgmpzYJM5JQjKu jgFCNuw9V8egk8v9f25K3viv+MT19zZjrCyKTNFig28Fda0EQqLvDYiWBbNBqmyt dtd0JOYx78ynVXUBue9dPGg2YvLXhVuftdESpkxMzjGxakFRrLD2klokn9sXT9Rf i2r5Ugu0gYqkVb93DcEy =+jNS -----END PGP SIGNATURE-----

1 0

tor 0.2.9.9 gcc 4.2.1
by grarpamp 30 Jan '17

30 Jan '17

Ancient gcc says src/or/connection.c:1843: warning: passing argument 1 of 'TO_OR_CONN' discards qualifiers from pointer target type src/or/connection.c:1843: warning: passing argument 1 of 'TO_OR_CONN' discards qualifiers from pointer target type src/test/test_dir.c:3700: warning: assuming signed overflow does not occur when assuming that (X - c) >= X is always true src/test/test_dir.c:3828: warning: assuming signed overflow does not occur when assuming that (X - c) >= X is always true src/test/vote_descriptors.inc:93: warning: string length '4135' is greater than the length '4095' ISO C99 compilers are required to support src/test/test_microdesc.c:654: warning: string length '5844' is greater than the length '4095' ISO C99 compilers are required to support src/test/test_descriptors.inc:305: warning: string length '10571' is greater than the length '4095' ISO C99 compilers are required to support

2 2

onionoo.tpo stuck at 2016-05-13 12:00
by nusenu 29 Jan '17

29 Jan '17

Hi Karsten, I was surprised that ornetradar did not send a single email for yesterday's new relays. After looking into it, it turned out it is an onionoo problem. "relays_published":"2016-05-13 12:00:00" https://onionoo.torproject.org/details?limit=4 regards, nusenu

2 11

./configure in 0.2.9.9 is ~broken?
by loki der quaeler 26 Jan '17

26 Jan '17

Hi - Trying to configure 0.2.9.9’s build with this command: ./configure --with-libevent-dir=/usr/local/lib --with-openssl-dir=/usr/local/openssl/ fails with: checking for libevent directory... configure: WARNING: We found the libraries for libevent, but we could not find the C header files. You may need to install a devel package. configure: WARNING: On most Redhat-based systems, you can get headers for libevent by installing the libevent-devel RPM package configure: error: Missing headers; unable to proceed. whereas this worked (and still works) when being issued against 0.2.8.12’s source code I have libevent-devel (and libevent-headers) installed on my system - and have been building tor on the system for many years now. Does this ring a bell with anyone?

2 4