tor-dev February 2017

tor-dev@lists.torproject.org

32 participants
31 discussions

Start a nNew thread

Tor Browser and Mozilla addon verification
by bancfc＠openmailbox.org 18 Feb '17

18 Feb '17

Hi, does Tor Browser check addon code for tampering for addons from the Mozilla server?

2 2

[release] metrics-lib/DescripTor 1.6.0
by iwakeh 17 Feb '17

17 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! Another release of metrics-lib/DescripTor is available: https://dist.torproject.org/descriptor/1.6.0/ - From the change-log: * Major changes - Deprecate DescriptorDownloader in favor of the much more widely used DescriptorCollector. * Medium changes - Parse "proto" lines in server descriptors, "pr" lines in status entries, and "(recommended|required)-(client|relay)-protocols" lines in consensuses and votes. - Parse "shared-rand-.*" lines in consensuses and votes. ... and quite a bit more see [0]. Please direct comments and questions to the metrics-team mailing list [1]. Cheers, iwakeh [0] https://gitweb.torproject.org/metrics-lib.git/plain/CHANGELOG.md?id=10042d3… [1] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYpyhdAAoJEPeEx9Sa/gvikq0QAKKhd2v04WGwokOGD+j7HNJC ylEamW7BSxMHCecgkMULy7RvTkmUmw/OJ66Ob2chdqVd6di8/fej3Sra+mpxcx9f mibg7UTLtMPgmoKMOp2qL7++HYuhWOowU+6e5rF1Ps0vVBZHWAD2iRCMX+jU2J+p XzYcVJ4YyV7ovfITDi1hDMvOXqDRrvhbH5bFDgXM0b5mWyKfjb/p35Y5wivEFPxp DYfVQ231IhDaN8ews3jXpuU8MILUBxzybOK+xtnAfYI4SXxMrJ16LmEpuP5lL2j8 9FfdG2U9MTdxnfEEYVPV/NrBRxZ9r+6d6pTtySmJ8D2s1hnwF3higTYm1DPCfU5U /m1AtLJsFvGVd/qJ4TNmWww8r1WgZlPzggVHgsHL28lpGK3L8ryQrbA0Nr6AVuFO sHDG4Fq5iegoWPsgGIcD8ThJlgvi5a6nS0l79OL+DUv4is2zQeI+zOgiaVeu/CmE JlRkMaA3U2AxayqBSJCwHKdFOu75cHCErTYEQt8Oy+h3rhrw2ucfUe/fKyMOVWps g156i/PsroggHMZWackXBv9tPJyK57ipTEr84ljg2jsZYTUsrYzN13+v/bkrOWXe jTOiicdFJ8Kfyj9Ng5afbLmt24W7BYQSqp4BM4MdEmZ2sY4Zq3iTPMqzBGai3OV4 8EJ5gsOCP7WEmSJcMNyg =EBek -----END PGP SIGNATURE-----

1 0

Prop224 oppurtunity: keygen, crypt, sign, encoding tools
by grarpamp 17 Feb '17

17 Feb '17

Tor could ship with a tool to offline generate all the various keys, encrypt and sign with them, for debug, test, and use with other apps that tie to tor. And a tool to translate strings between different encodings in use. Or at least provide howto and links in the docs to third party tools that users could use for key ops and translation. Since those howto topics appear on the lists now and then. We here might code up openssl, python functions, etc on the fly. However beginning users are typically looking for simple purpose dedicated tools, or example docs using prebuilt tools off the net. This tends to apply to budding application development in onionland, developing things that look at and use tor, etc.

5 4

GSoC 2017 - my name is Marcin
by Marcin Czarnecki 13 Feb '17

13 Feb '17

Hello all, tl;dr can go on about Tor and anonymity and privacy related things for hours, give me a chance I am studying Computer Science at the University of Brighton (in the UK). I am interested in participating in Google Summer of Code 2017 with the Tor project. I am a web security and anonymity enthusiast, tried to work with the Tor Project for GSoC 2016 but it did not work out. I have not contributed to the Tor's code base but have been an active, semi advanced user for past 3 years. Have been experimented with setting up exit-nodes (ended up with my box being considered the #1 most evil machine in the world :)), creating Tor-clearnet gateways, hosting own HS, trying to exploit other HSes, playing with encryption etc. I think that gave a me a lot of insight of how Tor works (still amazed and finding new things when reading docs). I am planning to base my proposal on the idea on a easier way of hosting HS so it would become more accessible to non tech savvy Tor users plus enforcing good security practices when hosting a HS (got some experience and cool ideas [citation needed]). My main skills are in Linux and back-end web development but I am also interested in scripting and automation as well as encryption. Can talk about Bitcoin for hours (security, anonymity, etc.), thinking about using that as my other project proposal as this should be the currency of Tor and more integrated into Tor (Tor Browser extension?). When it comes to programming I feel confident with PHP, Python and HTML, CSS, JS stuff, and know a bit of other languages but I am a fast learner! When it comes to tor related projects, two years ago I did this small crawler with web interface for searching (#2 most evil machine) in Python: https://github.com/marncz/torcrawler Cool feature on which I stopped working was HTTP headers fingerprinting which could led to grouping Hidden Services by hosts providers. Feel free to contact me: email: marnczarnecki[at]gmail.com IRC at OFTC: marncz Many thanks, Marcin

2 1

Issue regarding IRC channel
by Jaskaran Singh 12 Feb '17

12 Feb '17

Hi, As of writing this mail, I can't access the Tor-Dev channel on OFTC neither using my registered nick on desktop client nor through the web interface. Looks like the channel has turned invite only. Would be great if someone could look into this. Regards, Jaskaran Veer Singh

3 2

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses
by Vi Grey 08 Feb '17

08 Feb '17

> Here is the suggested scheme: > > onion_address = base32(version + pubkey + checksum) > checksum = SHA3(".onion checksum" + version + pubkey) Wouldn't SHA3 be computational overkill if we're just worrying about the checksum making sure the .onion address wasn't mistyped? My suggestion would be to use something like this for the checksum: checksum = HMAC-CRC32(".onion checksum", version + pubkey)[2:] (with the HMAC key as its first argument) HMAC-CRC16 could be used as well instead of a truncated HMAC-CRC32, but CRC16 is a lot less standard than CRC32. Also, should we consider including a Version option eventually in the ADD_ONION control port command when using a KeyBlob? It wouldn't matter much for this new version and probably wouldn't matter much for a while, but it might be good to keep this in mind for the future.

4 3

archive.is and archive.fo are using CloudFlare. Is the TorBrowser add-on cfc useless now?
by Christian Pietsch 07 Feb '17

07 Feb '17

Hi Yawning, hi all, sorry if this is old news, but I just noticed that archive.is not only redirects me to archive.fo (which I noticed before), but archive.fo now greets me with a CloudFlare captcha. Considering that cfc was created in order to evade the CloudFlare captcha, this is quite a disappointment. Is cfc useless now? Can it be fixed? David F suggested using Memento which I think is an interesting idea, having participated in one of their hackathons. One caveat: Memento would point to to various archives not all of which might be suitable. What is the reason why archive.org is not used? I hear they are almost done setting up an onion service for the Internet Archive. Cheers, C: On Mon, Apr 18, 2016 at 10:16:31PM +0000, Yawning Angel wrote: > Source: https://git.schwanenlied.me/yawning/cfc -- Christian Pietsch, volunteering for Digitalcourage e.V., Bielefeld, Germany Nominations sought for the German Big Brother Awards: https://bigbrotherawards.de Verfassungsbeschwerde gegen Vorratsdatenspeicherung: https://digitalcourage.de/weg-mit-vds Appell gegen den geplanten Datenschutz-Abbau: https://digitalcourage.de/rettet-den-datenschutz Umfrage zum Datenschutztag 2017: https://datenschutztag.org/survey/

2 2

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev February 2017