tor-dev

tor-dev@lists.torproject.org

3581 discussions

GSoC 2021 - Alexa Top Sites Captcha and Tor Block Monitoring
by Apratim Ranjan Chakrabarty 24 May '21

24 May '21

Hello everyone, I'm Apratim (irc: _ranchak_), and I'm from Haldia Institute of Technology, India, studying Computer Science Engineering. I'll be working this summer on the GSoC project: "Alexa Top Sites Captcha and Tor Block Monitoring" with my mentors Barkin, Pili, Gerog and Roger guiding me through the irc. I'm very excited to be a part of Tor and am interested in working on this project! Briefing about the project: As of now "The Captcha Monitoring" project tracks how often CDN (for ex. Cloudflare, Akamai, Amazon Cloudfront, etc.) fronted webpages return CAPTCHAs to Tor clients. My project will be focussed on tracking the The Alexa Top 500 Websites, to give a detailed perspective of websites mentioned in the Topsites, blocking or returning Captchas to Tor clients. The project aims to do so by fetching webpages over a period of time from both Tor clients/browsers and the non-tor browsers thereby comparing the results. The results will be then collected and provide answers to the different metrics, and also form an understanding of how websites are blocking Tor and affect Internet freedom. Also one could visit: https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/GSoC-2021 for detailed info. As planned and discussed by my mentor, I'll be creating more issues, which could be seen from the sidebar along the wiki page, to record my progress. As of now one could reach out with suggestions and advises in the irc (#tor-dev) as well as here: tpo/community/support/#40013. I also plan to update my wiki page frequently and have all the information required. Hope to have a great learning ahead and enjoy this summer! Regards, Apratim

2 2

Consensus network status fetch
by sysmanager7 16 May '21

16 May '21

Why does a network status fetch cause a signal hup and my system to reset? 00:30:35 [NOTICE] While not bootstrapping, fetched this many bytes: 17796869 (server descriptor x fetch); 8622 (server descriptor upload); 2216044 (consensus network-status fetch); 148431 x (microdescriptor fetch) x 00:00:07 [NOTICE] Read configuration file "/etc/tor/torrc". x 00:00:07 [NOTICE] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". x 00:00:07 [NOTICE] Received reload signal (hup). Reloading config and resetting internal state. xlq May 13, 2021 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 3

descriptor sync finished event after disabling UseMicrodescritors
by nusenu 16 May '21

16 May '21

Hi, what is the best way to find out when descriptor fetching is completed after temporarily disabling microdescriptors on a running tor client daemon? The temporary disabling of microdescriptors is done using this line in a python script using stem: controller.set_conf('UseMicrodescriptors', '0') Is there a better way than to try and re-try after 10 seconds in a loop via controller.get_server_descriptors() ? I also noticed that fetching takes significantly longer when microdescriptors are disabled temporarily when compared to adding UseMicrodescriptors 0 to the torrc file persistently and restarting the tor client. Can I tell tor to "fetch now" directly after controller.set_conf('UseMicrodescriptors', '0') via an additional control command? kind regards, nusenu -- https://nusenu.github.io

3 3

Uptime stats for "Tor user can access an otherwise-functional hidden service"?
by Holmes Wilson 06 May '21

06 May '21

Hi everyone, I’m building a messaging app based on Tor v3 onion services and I’m wondering what kind of uptime expectations we should set with users and other stakeholders. Is there data over time on uptime for onion service functionality? That is, not for a particular onion service, but for something like, given that the user’s access to Tor is not being limited by their ISP, and given that the onion service is fully operational, whether a Tor user can reach the onion service? Some more concrete versions of this question are: 1. For what percentage of time over a given time period (say the past 3 years) are there no known network-wide problems affecting onion services? 2. What percentage of attempts by a user attempting to connect to a onion service are successful, assuming no successful censorship of the user’s network? 3. Is there some incident log somewhere of problems that affected onion services network wide that includes how long these problems persisted for? (I don’t see any onion service outage notes in this document, though I seem to remember there was an issue a few months back? https://metrics.torproject.org/news.html <https://metrics.torproject.org/news.html>) I see there’s uptime data for various relays, but I’m not sure how to translate this into a meaningful answer to the two above questions. Are there any good answers to these questions out there in the wild? Even approximate answers or lower bounds for uptime are fine and super helpful! Thanks!!! Holmes

3 3

What's the best way to learn about critical updates to Tor?
by Holmes Wilson 06 May '21

06 May '21

Hi all, For the messaging app we’re building on Tor (not Tor browser) what’s the best way for us to be alerted when there are critical updates to Tor, so that we can prepare a new release as quickly as possible? (Apologies for the flurry of questions today!) Holmes

2 1

ClientAuthV3 for v3 onions via Tor controller is accepted by ADD_ONION but seems to get ignored
by Miguel Jacq 04 May '21

04 May '21

Hi there, I'm one of the OnionShare developers and I'm trying to implement the new support for ClientAuthV3 via the controller as per [1] (thanks for adding it!). Since OnionShare depends on Stem, I also began by adding support for passing the ClientAuthV3 argument and V3Auth flag into Stem (I intend on submitting that as a PR once I solve the problem below, but I think the problem isn't Stem specific) I can send the ClientAuthV3 base32-encoded public key and the V3Auth flag to ADD_ONION, and get a 250 response back. The problem is that when I then visit the onion address, it doesn't actually require the Client Auth that was set :) I am running the nightly Tor on Debian 10 (Buster): ``` Tor version 0.4.7.0-alpha-dev. Tor is running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.3.8 and Glibc 2.28 as libc. Tor compiled with GCC version 8.3.0 ``` Steps to reproduce: 1) Take these public and private base32-encoded strings (as generated by [2], if you want to generate different ones) public: FGTORMIDKR7T2PR632HSHLWA4G6HF5TCWSGMHDUU4LWBEFTAVYQQ private: 5ZTNYVGHGMBCWT47YQT4ZFOFBWYU24C5PRQZ2CRCXZ5FKTVMJ7QA 2) Start a simple service on localhost:9735: ``` echo Hi | nc -l 127.0.0.1 9735 ``` 3) Connect to Tor's control port and add an onion with a private key that will derive the onion address rujvluxdgiibem3odopgkgiiajgtwfbdgkuqfyydhl5qupotpwyxjaid.onion (or put your own if you wish): ``` user@onionshare:~$ sudo telnet localhost 9051 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. authenticate "" 250 OK ADD_ONION ED25519-V3:MNkxu0oI0CX6Oq1AEroRGSAiqXurEbzBdraDKJB1pkNkl9hNCr+bagdAg7gA4F3M/FrF7BHBdh5zdvkHB7oO4w== ClientAuthV3=FGTORMIDKR7T2PR632HSHLWA4G6HF5TCWSGMHDUU4LWBEFTAVYQQ Flags=V3Auth Port=80,9735 250-ServiceID=rujvluxdgiibem3odopgkgiiajgtwfbdgkuqfyydhl5qupotpwyxjaid 250-ClientAuthV3=AUEFTXH34ZVRXIIVOK5G7XLHTUXGVRLLXG7DG3NKJLRCVSEEHQDQ 250 OK ``` 4) Visit http://rujvluxdgiibem3odopgkgiiajgtwfbdgkuqfyydhl5qupotpwyxjaid.onion and expect to get the Tor Browser pop-up dialog '[onion service] is requesting that you authenticate.. Enter your private key for this onion service'. etc Instead: the service loads 'Hi' without any requirement for Client Auth occurring. I never added the private key to Tor Browser in any way. Is it a bug, or am I doing it wrong somehow? Thanks! mig5 [1] https://gitlab.torproject.org/tpo/core/tor/-/issues/40084 [2] https://github.com/pastly/python-snippits/blob/master/src/tor/x25519-gen.py

2 2

Free and Open Communications on the Internet (FOCI) submission deadline May 13
by Roger Dingledine 22 Apr '21

22 Apr '21

Hi folks! The FOCI workshop is happening again this year, organized by our friends Eric Wustrow (Tapdance, Conjure) and Dave Levin (Geneva). The deadline for submissions is May 13. Cecylia, Arturo, me, Alberto from IODA, Tariq, Rob, phw, etc are all on the program committee: https://conferences.sigcomm.org/sigcomm/2021/workshop-foci.html So: if you have something you want to share with the FOCI audience, consider writing it down and submitting. :) Thanks! --Roger

1 0

Hackathon UDP Support
by Matthew Finkel 14 Apr '21

14 Apr '21

Hello! During the Hackweek, I spent a little time hacking support of UDP-over-Tor. The goal of the project was supporting UDP onion services, and leaving Exit support for another time. I didn't have a working implementation by the end of the week, but life moves one. This is an initial mail about the general idea, and I'll follow up with a concrete proposal in the not-too-distant future. I have a (currently broken) branch `feature_udp_data` in my gitlab repo [0]. I started simplifying/refactoring the hack job, but it's still a work in progress. I'll briefly describe how the working version [1] is designed. Overall, this mostly just-works. While UDP is not a reliable routed protocol, datagrams are not dropped within the network. We delegate drops to the edges' recv/send queues (and any intermediate network equipment). Client Side: The patch continued our dependence on SOCKS5 [2] and (maybe correctly) implemented the UDP ASSOCIATE command. The client sends a normal SOCKS5 handshake, except the new command is 0x03. The tor client then: - Establishes a rendezvous circuit with the specified onion service hostname in the handshake - On completing that connection, creates and binds a datagram socket - Sends the application a Success response and includes the datagram socket's bound address and port in that message. The client then sends all datagrams to the provided (bound) address:port, and the TCP socket used in the SOCKS5 handshake is only kept open as a way of tracking the UDP socket's lifetime. Tor knows that any datagram payload should be transported as a datagram instead of a stream. Tor Internal: The patch introduces two relay cell commands: DATAGRAM and DATAGRAM_FRAG. These relay cell types are stateless. Simply, when a tor client (or general edge, in the future) receives a DATAGRAM_FRAG relay cell, it knows that the payload is only a fragment of an entire datagram. As a result, tor queues the data and does not send it to the application. When a DATAGRAM cell is received, then tor knows the contained payload is either: 1) a complete datagram that fit into a single relay cell 2) the final payload of a fragmented datagram In either case, tor appends the payload to the (possibly empty) queue and then sends it to the application. Tor doesn't need to care which one is the current case. Also, Tor doesn't take into account a MTU mismatch between the client-side and server-side - future work. As an aside, I considered introducing only a single DATAGRAM relay cell, and reserving the first byte for metadata (and using a bit indicating if the payload is a fragment). However, I couldn't convince myself that losing one byte of payload capacity was worth the advantages. I'll leave this as a valuable discussion during the proposal process. Onion Service Side: The onion service is configured normally, except now there is a HiddenServiceType configuration option. When it isn't provided, the default value is "stream", otherwise it should be "dgram". This configuration tells tor that a "stream" opened to this onion service (on the specified port) is actually connectionless, and any payload data should be sent and received as datagrams. Following from the previous section, when a DATAGRAM relay cell is received, the queued payload is packaged as a datagram and sent to the configured onion service address:port. Future design considerations: - Better client-side interface than SOCKS5 UDP Associate? - Relay cell design improvements - Cleaner onion service configuration? - MTU difference on the client/server-sides - What's missing before we can support this on Exits? [0] https://gitlab.torproject.org/sysrqb/tor/ [1] commit ebfb4a97713d49a5e7f61709658b9d55ac21ec95 [2] https://tools.ietf.org/html/rfc1928

1 0

Question about hidden services shared by multiple hosts
by Holmes Wilson 10 Apr '21

10 Apr '21

Hi everyone, We’re working on a peer-to-peer group chat app where peers connect over v3 onion addresses. One issue are groups where there are many users but only a few are online in a given moment. Onion addresses are forever, and existing peers might know every peer in the network, but it will take a while to try connecting to all of them to find one that is online. In this case, it seems helpful for one or more peers to share one or more onion addresses that would serve as reliable “trackers", e.g. 1. All members know the keypairs for these addresses. 2. All online members ping these addresses at random intervals to say they’re online. 3. If they can’t connect to an address, they start hosting it themselves. We’re going to start testing it, but we’re wondering if folks here know the likely outcome of trying to “share” hosting of an onion service in this spontaneous-volunteer sort of way and if there are downsides. I *think* the most important question is how long it takes for the network to stop routing incoming traffic to an offline client when there’s an online one available. How long will the address likely be unreachable in one of these transition moments, assuming some peer immediately detects that a “tracker” onion address has gone offline and begins hosting it themselves? (And does this question make sense?) Thanks! Holmes

3 4

sigstore for improving verification of downloads?
by axel simon 08 Apr '21

08 Apr '21

Hello all, I've been a Tor user for a long time, have helped a bit with translation at times, and been working on issues related to freedom and the Internet for a while (as part of La Quadrature du Net), but i'm writing today with my work hat on, as a member of the security team at Red Hat's office of the CTO. We recently announced a new project called sigstore [1], which could be summarised as "Let's Encrypt, but for software provenance and code signing". If you want to read other people explain it better than me, i found these two articles did a good job: - https://www.darkreading.com/application-security/linux-foundation-debuts-si… - https://www.zdnet.com/article/linux-foundation-announces-new-open-source-so… In any case, the idea is to provide a public good service, heavily inspired by Let's Encrypt, that lets developpers sign packages, containers, code artifacts in general, and lets user verify them in a simple way. It's still early days, but the aim is to make it a lot easier to verify the integrity of software, and to do better and easier than "here's a binary, here's an .asc detached PGP signature, here's a page that says that 0xBLA is our public key", which as we know is a procedure most users simply don't follow. To avoid the pains of key management (and the nasty targets keys quickly become), sigstore uses ephemeral signing keys (which don't ever touch the disk), publishes the signature in a first transparency log, and discards the key after signature. The other part of the system, which connects a signing key to an entity, is based on issuing a certificate to the signer which contains their email address and their pubkey, if they can prove control of the email address using OpenID Connect. This certificate is then stored in a second transpararency log, which provides a second root of trust, directly inspired by the Certificate Transparency project [2]. Using both transparency logs (signatures and certificates), one can then verify that a binary download is the expected one, and that is was signed by someone who controls an email address. Tools are being built to do this automatically, and in a repeatable way. The idea is also to make it easy for developers to monitor the certificate transparency log for their email, which could alert them to untowards actions, if a new certificate pops up for something they never signed. The OpenID Connect part is designed to allow for both large ID providers (like Github or Google) and bring-your-own. As i was saying, it's still early days, but it's coming along nicely and in my mind, Tor (and TAILS) are projects that would very much benefit from sigstore, hence this email. Work is currently under way with the Ruby and WebAssembly communities to help them use sigstore to sign their stuff, and more generally the project has been well received so far. The whole system is, of course, free and open source and i might add, welcomes new contributors. [3] We also have a chat, if anyone is into that kind of thing. [4] Interested in your thoughts, critiques etc. Thanks and hope this is helpful! axel 1. Jointly with Google and Purdue University, https://sigstore.dev 2. https://certificate.transparency.dev/ 3. https://github.com/sigstore 4. https://join.slack.com/t/sigstore/shared_invite/zt-mhs55zh0-XmY3bcfWn4XEyMq… -- axel simon axel(a)redhat.com // axel+tor(a)axelsimon.net

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev