November 2015 - tor-dev - lists.torproject.org

Just releasted : haskell-tor
by Erik de Castro Lopo 19 Nov '15

19 Nov '15

Hi all, Galois Inc has just released an implementation of the Tor protocol implemented in the Haskell programming langauge: https://github.com/GaloisInc/haskell-tor The Readme states: This is an early implementation of Tor that has not been peer-reviewed. Those with a true, deep need for anonymity should strongly consider using the mainline Tor client until and unless this version receives appropriate extensions, testing, and review. I'm not (yet) associated with this project but thought it should be mentioned here. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

8 9

prop224: "revision-counter" field leaks service/intro point stability
by Tim Wilson-Brown - teor 18 Nov '15

18 Nov '15

Hi all, The hidden service descriptor's "revision-counter" field is incremented every time the descriptor is updated. I wonder what the distribution of these versions will be: * a hidden service with a value of 0 (or 1) has just started up (or just rolled over to a new period) * an unstable hidden service might have an unusually high count * if enough introduction points go down or are DoSed, the hidden service will find new ones, and increment the count Should we randomise the start value and increment? How can we do this in a way that doesn't lead to exhaustion of the revision-counter? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

1 0

Alternate Single Onion Service Designs
by teor 17 Nov '15

17 Nov '15

Hi all, Do we need both single onion services (Proposal 252) and rendezvous single onion services? We want to enable secure usage by default, and avoid splitting anonymity sets. But we also want to support real-world use cases, because anonymous protocols are safer if more people use them. There are currently two different proposed single onion service designs: * Single Onion Services (SOS - Proposal 252): require an ORPort, no introduction/rendezvous, one-hop extend * Rendezvous Single Onion Services (RSOS - No Proposal Number): introduction/rendezvous with one-hop paths I see at least the following scenarios for using these alternate single onion service designs: 0. an onion service operator who wants to minimise latency and maximise bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous protocol) 1. an onion service operator runs a SOS for new clients, and an RSOS for old clients (a RSOS is compatible with current clients, a SOS Is not) 2. an onion service operator who can’t expose an ORPort runs a RSOS for all clients (there are enclave and NAT configurations where external ports are an issue) 3. an onion service operator who wants to use Proposal 255 for load-balancing runs a RSOS, and splits their introduction and rendezvous instances by passing the introduction over the control port (proposal 255 relies on the rendezvous protocol to handoff the rendezvous point connection to another Tor instance) 4. an onion service wants low latency and better bandwidth, and doesn't want to wait until the SOS feature is developed and deployed (SOS is a larger feature, and it needs client changes). They'll switch to SOS when it's well supported by installed versions of Tor Browser. Given these use cases, I think we could implement both flavours of single onion service. But this splits the onion service anonymity set at least 3 ways (and maybe also by some other onion service features). I'm not sure how much of an impact this will have - it does depend on our threat model for each flavour of onion service. If we wanted to generate more onion service cover traffic, we could move various automated Tor Browser actions (such as update checks and update downloads) to appropriate flavours of onion service. This would shift load away from exits, and also have address authentication benefits. (Tor Browser wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.) The other mitigations I'm aware of are cover traffic and lookalike protocol interactions, but these require significant research and design work. We're working on implementing rendezvous single onion services in #17178. I think they're pretty close: we need to do some more testing, and handle some edge cases. RSOS servers work with existing clients, including current Tor Browser releases. Single onion services (Proposal 252) is a larger feature, so it's a bit further away. SOS are incompatible with current clients, so supporting code will need to be deployed in Tor clients (such as Tor Browser) as well as on the onion service itself. After the feature is ready, there will be some lead time before SOS are usable with the majority of deployed Tor clients. What do you think? Are onion services big enough to safely have multiple flavours? Could they get that big if we support enough functionality? Or are we better to implement secure, one-size-fits-all defaults, and ask users and operators to sacrifice some performance? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

5 4

Re: [tor-dev] Patched versions of the FreeBSD ports "security/tor" and "security/tor-devel"
by Vinícius Zavam 17 Nov '15

17 Nov '15

2015-11-05 12:08 GMT-03:00, Vinícius Zavam <egypcio(a)googlemail.com>: > Ahoj! > > If you are using FreeBSD to run a Tor Relay, it would be sweet to get more > feedbacks about the patches I reported to the FreeBSD Bugzilla, so they can > be commited/improved. > > Please check https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203014 > > Thanks. > > > -- > Vinícius Zavam I just changed a bit the patches; please check if everything still works for you and ping me back if needed. Previous tests went well for i386 and amd64. Because there are no TOR_LDFLAGS_tcmalloc or TOR_TCMALLOC_LIBS available, I ran into changes to the main LDFLAGS (that's why tor-dev@ is reading this answer in CC now). K.R., -- Vinícius Zavam keybase.io/egypcio/key.asc

1 0

Weird interactions between TBB and Hidden Services upon HS kill/restart
by Alec Muffett 17 Nov '15

17 Nov '15

For the sake of documentation I thought I would share this here: I have a (test) Hidden Service, running vanilla tor 0.2.6.10 The HS torrc is: ControlPort 9051 DataDirectory /home/alecm/tor-dev/data SafeLogging 0 Log info stdout HiddenServiceDir /home/alecm/tor-dev/hs HiddenServicePort 80 localhost:80 SocksPort 0 RendPostPeriod 0 seconds I also have an OSX version of Tor Browser Bundle - version 5.5a4 (tor 0.2.7.4-rc) I amended /Applications/TorBrowser.app/TorBrowser/Data/Tor/torrc-defaults to include: SafeLogging 0 Log info file /tmp/tor-log.txt ...so that I can see what is going on. I launched the Hidden Service (HS) I accessed the HS from TBB - Successful Page Load! The TBB logfile contains the following sequence, pertinent to the first connection attempt, with manual edits: ---- start ---- >Nov 12 17:41:13.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_1', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_1 >Nov 12 17:45:02.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'MY_ONION' >Nov 12 17:45:02.000 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor MY_ONION. Fetching. >Nov 12 17:45:02.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_1', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_2 >Nov 12 17:45:03.000 [info] circuit_get_open_circ_or_launch(): Chose INTROPOINT_1 as intro point for 'MY_ONION'. >Nov 12 17:45:03.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. >Nov 12 17:45:03.000 [info] link_apconn_to_circ(): Looks like completed circuit to hidden service does allow optimistic data for connection to MY_ONION ---- end ---- This looks good. I killed the HS - the means of killing appears immaterial, SIGINT, SIGTERM, same thing always happens. I waited about 60 seconds. I re-launched the HS. I accessed the HS from (still running, not restarted) TBB using Shift-Reload to force a page-refresh - Failure! The TBB logfile contains the following sequence, pertinent to the second connection attempt: ---- start ---- >Nov 12 17:46:27.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'MY_ONION' >Nov 12 17:46:27.000 [info] circuit_get_open_circ_or_launch(): Chose INTROPOINT_3 as intro point for 'MY_ONION'. >Nov 12 17:46:27.000 [info] rend_client_introduction_acked(): Got nack for MY_ONION from INTROPOINT_3... >Nov 12 17:46:27.000 [info] rend_client_report_intro_point_failure(): 2 options left for "MY_ONION". >Nov 12 17:46:28.000 [info] rend_client_introduction_acked(): Got nack for MY_ONION from INTROPOINT_2... >Nov 12 17:46:28.000 [info] rend_client_report_intro_point_failure(): 1 options left for "MY_ONION". >Nov 12 17:46:28.000 [info] rend_client_introduction_acked(): Got nack for MY_ONION from INTROPOINT_1... >Nov 12 17:46:28.000 [info] rend_client_report_intro_point_failure(): No more intro points remain for "MY_ONION". Re-fetching descriptor. Okay, this makes sense, all the IPs are invalid because I killed the daemon, none of them are reachable... >Nov 12 17:46:28.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_2', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_3 Wait, is it relevant that it has picked descriptor ID 'MY_DESC_2' here, not the prior 'MY_DESC_1'? The latter crops-up further down. Perhaps this is a DHT thing? This is the only reference to MY_DESC_2... >Nov 12 17:46:29.000 [info] rend_cache_store_v2_desc_as_client(): Service descriptor with service ID MY_ONION, every intro points are unusable. Discarding it. That sounds okay, garbage collection of dead data is good... >Nov 12 17:46:29.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_1', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_4 Wait, now we are re-fetching MY_DESC_1 again?... >Nov 12 17:46:30.000 [info] rend_cache_store_v2_desc_as_client(): We already have this service descriptor MY_ONION. And it thinks we already have it? But didn't we just discard it?... >Nov 12 17:46:30.000 [notice] Closing stream for 'MY_ONION.onion': hidden service is unavailable (try again later). And there is the connection failure, and it looks like it didn't find a new descriptor, or rejected a new one if it found it - assuming it found it at all... >Nov 12 17:46:30.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. >Nov 12 17:46:30.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. Try "reload" again, just for good luck: >Nov 12 17:46:40.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'MY_ONION' >Nov 12 17:46:40.000 [info] connection_ap_handshake_rewrite_and_attach(): Unknown descriptor MY_ONION. Fetching. >Nov 12 17:46:40.000 [info] directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'MY_ONION' with descriptor ID 'MY_DESC_1', auth type 0, and descriptor cookie '[none]' to hidden service directory HSDIR_2 >Nov 12 17:46:41.000 [info] rend_cache_store_v2_desc_as_client(): We already have this service descriptor MY_ONION. >Nov 12 17:46:41.000 [notice] Closing stream for 'MY_ONION.onion': hidden service is unavailable (try again later). >Nov 12 17:46:41.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. >Nov 12 17:46:41.000 [info] rend_client_note_connection_attempt_ended(): Connection attempt for MY_ONION has ended; cleaning up temporary state. ---- end ---- So, it looks like one of three things: - perhaps TBB is not actually discarding the dead descriptor - or perhaps TBB is re-fetching the old descriptor and failing connections again - or perhaps TBB is fetching the new descriptor and rejecting it in favour of the old one, which it hasn't really discarded. In any case: killing TBB and restarting it seems to fix this situation, so it's something on the client side at fault? - alec

3 2

Percentage of Windows users
by Rob van der Hoeven 17 Nov '15

17 Nov '15

Hi folks, I am currently working on an isolating Tor proxy for Linux users. This proxy could be ported to Windows but this would be a lot of work. So I wonder if it's worth the trouble. What percentage of users are downloading the Windows version of Tor? Regards, Rob. https://hoevenstein.nl

1 0

Proposal: Link Cryptographic Agility
by Yawning Angel 16 Nov '15

16 Nov '15

Hello, There's been talk of moving to a wide block construct for cell crypto (#5460), and for adding PQ Forward Secrecy to traffic (#17272). To facilitate this, there needs to be a method for negotiating which primitives a given relay supports. To that end, here's the begining of a proposal (tentatively #260) that adds a `CIPHERSUITES` cell to the version negotiation process which allows relays to advertise the link cryptography primitives that they are willing to accept. TODOs/TBD: * Should the new cell be variable length? Our development cycle and how often we switch handshakes/link crypto tells me "No", the existing "VERSIONS" cell format tells me "Yes". * We need to revise prop. 249 to add a cell crypto method specifier to CREATE2V/EXTEND. * Proposal 249 does not cover changing RELAY_EARLY behavior, which will potentially cause problems (Eg: Ring-LWE + ntor will require between 5 to 9 fragments depending on the exact primitives). * The actual hybrid construct is deliberately left unspecified. * With runtime negotiation of primitives on a per-circuit basis, we introduce the possibility of downgrade attacks. We do calculate the SHA256 digest of VERSIONS/CERTS/AUTH_CHALLENGE cells (which will become VERSIONS/CIPHERSUITES/CERTS/AUTH_CHALLENGE), so we could do something like: auth_input = verify | ID | B | Y | X | SLOG | PROTOID | "Server" Where SLOG is the digest without too much difficulty... The alternative to all of this would be something like including handshake methods/supported link crypto in the descriptors, but that seems silly. Regards, -- Yawning Angel

2 2

W3C Payment Groups
by Jeff Burdges 16 Nov '15

16 Nov '15

I've been talked into formally participating in the W3C Payment Interest/Working Group as part of working on GNU Taler, well my employer INRIA is a member. Drop me a line if there is anything I can do/say/watch to help keep that potential standard tor friendly. Best, Jeff p.s. There are related groups on privacy and credentials that might be of more interest to Tor Browser which I'm not involved in, btw. p.s.2 Just fyi, Taler is a transaction system based on RSA blind singing. We haven't finished the demo for Taler yet, probably by 32c3 though. Feel free to look at these if you want to know more : http://taler.net http://grothoff.org/christian/taler-draft.pdf

1 0

Upcoming Onionoo version 3.0 will support searches by space-separated fingerprint
by Karsten Loesing 15 Nov '15

15 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Onionoo client developers, the upcoming Onionoo version 3.0 will support searches by space-separated fingerprint. To give you an example, the following two searches will both return moria1 as result, using the new version 3.0: "9695DFC35FFEB861329B9F1AB04C46397020CE31" "9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31" (In the current version 2.6 that second search wouldn't return anything, because it would look for a fingerprint starting with 9695 *and* starting with DFC3 *and* starting with...) You can try out the new behavior by using the Onionoo/Atlas/Globe mirrors run on thecthulhu.com: https://atlas.thecthulhu.com/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.thecthulhu.com/#search/9695%20DFC3%205FFE%20B861%20329B%209F1… The corresponding service instances run on torproject.org have not been updated yet, so that only the first search will return a result: https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020C… https://atlas.torproject.org/#search/9695%20DFC3%205FFE%20B861%20329B%209F1… (not expected to return anything until November 15, 2015!) The torproject.org instances will be updated in a month from now to give you the chance to update your clients. After all, your client might rely on the current behavior of the search parameter. (That's why this is a major protocol change, not because it's a major step towards world domination.) Please tell me if the new behavior doesn't work for you and you need me to make any changes/extensions. More details on the ticket: https://trac.torproject.org/projects/tor/ticket/17115 All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWHjKCAAoJEJD5dJfVqbCr+o0H/3Q37+YVS1d2enBa+Z/aEZkx b21/vvIUHMjBWCh41MAEJrQNzczfrjhusjkSpY1amypE6R81mST8mizFvtKK5zVh P4QlB9L40tKRrASwK1Tz+qSRmx7A6fm4YSieAALuvcD8LeNfwzNlKRqNSoipwDWl 7NjITYhOeRmExbUjfqDbfs5woodsabHaXIrAOUeQvtljc36bj1OGtq15UroaqLdv MKjn7GgP3qR5NrPAZKYlAVW7Qxg6KIsPC9DXam7xh4CIyWja01WsKrUab80fUT0K N7wvq4oV7PZ84BomVG/Fte2Vk5hz2e53deshsxwjVB2BonHKpq+hzHsLX+pkCSU= =0cnD -----END PGP SIGNATURE-----

2 4

Re: [tor-dev] . tor-roster's geo diversity badge and self-ref relays
by Sean Saito 15 Nov '15

15 Nov '15

Hi nusenu, >Do you consider in-family diversity so important - even though all of >them are run by a single entity anyway? > How about having a badge for tor network wide diversity? > I'd consider the tor network's overall diversity far more important than > in-family diversity because clients won't use more than one relay of a > given family anyway. Entire-network diversity is obviously more important than within-operator diversity---no doubt about that. We are doing within-operator diversity simply because the it's easier to measure/understand. I agree that measuring a family's relay diversity with respect to the entire Tor network is would be supplementary, maybe even strictly better. I am already logging relevant data, namely the number of relays per country and total CW per country (as you suggested previously). The former stastic could be used for badges like "First relay in country X." >More than 4/5 of the family's CW is located in countries with a cw lower >than 2%* (currently means non-top 7 country) and ASes lower than 1.5%* >(currently means non-top 8 AS)? > >That implies some degree of in-family diversity since a big family would >have to spread across multiple countries/ASes Although there have been some interesting discussions about which ASes to prioritize in putting new relays, an actual concrete numerical measure is thus far an unsolved problem. Virgil and I have talked about using a new tool (http://labs.apnic.net/vizas/) to observe which ASes have more interconnections and award bonus points to new relays on them. When these measures become better established definitely in favor of making badges for them (perhaps even replacing the within-operator diversity badges?). >"No Self-Referencing Relays" >I'm not sure what exactly you mean by that but I assume it is a MyFamily >config where a relay includes his own fingerprint. Why does that hurt? >The unnecessary descriptor space/bw? This is something Virgil wanted because he thought self-connections were ugly. If the penalizing of self-connections is found to be uglier than the self-connections themselves, we're both fine with removing it. Hope this answers your questions. Thanks for the feedback! Best, Sean

7 6