- tor-access - lists.torproject.org

GitLab Account Request for GSoC Contribution
by harshita roonwal 10 Mar '25

10 Mar '25

Hello Tor Project Team, I am interested in contributing to the Tor Project as part of Google Summer of Code (GSoC) 2025. Specifically, I want to work on the Relay to Relay Connectivity in the Tor Network project. To do so, I need access to GitLab for: - Reviewing and discussing project issues. - Contributing code and submitting merge requests. - Communicating with mentors and other contributors. Here are my details: - Name: Harshita Roonwal - Preferred Username: harshita_r - Email Address: roonwal721972(a)gmail.com - GSoC Project Interest: Relay to Relay Connectivity in the Tor Networ Looking forward to your approval. *Best Regards*

1 0

IETF Standardization of Blinded Tokens
by Peter Story 05 Jan '21

05 Jan '21

Since there was earlier discussion about a “specification for bypassing CAPTCHAs using blinded tokens” in this mailing list, I thought I would provide an update. It seems that CloudFlare now has a “PrivacyPass" tool which implements just such a technology: https://privacypass.github.io/ The tool is linked from CloudFlare’s CAPTCHA page. To see it for yourself, just create a clean Tor Browser session, then navigate to webmd.com (they see to be quite aggressive about blocking Tor users). Also, the protocol the tool uses is in the process of being standardized: https://datatracker.ietf.org/wg/privacypass/about/ https://github.com/ietf-wg-privacypass/base-drafts I’m not a cryptographer, but perhaps those who are could provide feedback. It would be great to see this succeed and thereby eliminate CAPTCHAs from many websites. -Peter

1 0

Google reCAPTCHA
by grarpamp 26 Mar '18

26 Mar '18

On Sun, Mar 25, 2018 at 6:15 PM, nusenu <nusenu-lists(a)riseup.net> wrote: > The unbearable situation with Google's reCAPTCHA Last months many more times it does not even display the captcha to solve but just says spam. And if display, often takes 5-10 correct solves to pass. Who is actively inquiring and lobbying Google to get this changed?

1 0

Block by google... is it possible to bypass google IP checks ?
by Muppet96 12 Jul '17

12 Jul '17

Hi, is there any way to use google search engine and Tor ? Every time when I`m trying to find out something, I see recapture and in the final step google disconnecting me from the search engine. How to bypass it ? Muppet96 Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Does CloudFlare ever expire Tor Exit Nodes?
by teor 02 Mar '17

02 Mar '17

Hi, We've just received some feedback from a Tor relay operator who accidentally made their relay an exit for a short time. Apparently this places them on the CloudFlare Tor list, and it's not clear if this will ever change. If there is no expiry, then there is a denial of service risk. Anything that behaves like this will fill the list with entries: * Start an Exit with an IPv4 address and get it on the CloudFlare list * Move to the next IPv4 address It doesn't even have to be malicious: home broadband routers and cheap VPSs tend to behave like this when configured as Exits, as the load sometimes causes them to crash. Tim > Begin forwarded message: > > From: Paw <pawsen(a)gmail.com> > Subject: Re: [tor-relays] Remove IP from list of known Tor exit nodes > Date: 3 March 2017 at 04:45:37 AEDT > >> So it wouldn't surprise me if Cloudflare won't unlist your IP on request > You are right. I have written some mails to support(a)cloudflare.com <mailto:support@cloudflare.com>. > According to > https://support.cloudflare.com/hc/en-us/articles/203306930-Does-Cloudflare-… <https://support.cloudflare.com/hc/en-us/articles/203306930-Does-Cloudflare-…> > Cloudflare updates its list of Tor exit node IP addresses every 15 minutes. > But the reply I got from their support was: >> it's not listed on honeypot it is not based on any maliscous activity >> but rather was a special list of TOR endpoints curated by the request >> of our customers to control access to their sites. As such your >> endpoint won't be removed from that as it is a TOR endpoint this is >> completely independent of the reputation. > They have not registered any malicious activity from the IP and it is > not figuring on https://check.torproject.org/exit-addresses <https://check.torproject.org/exit-addresses>, but still > they won't remove it from their list. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

1 0

Specification for bypassing CAPTCHAs using blinded tokens
by Alex Davidson 31 Dec '16

31 Dec '16

Hi everyone, I've been interning at Cloudflare for the past 3 months and have been working on developing an implementation of the blinded tokens spec that George and Filippo developed a while back. We've updated aspects of the original spec, the newest spec can now be viewed here: https://github.com/cloudflare/challenge-bypass-specification. We're happy to hear comments from any of you on the design and on the capacity of the solution for preserving anonymity. We've managed to build a test copy of the protocol along with an extension that carries out the required operations. The extension is not completely finished yet, but we're looking towards making that open source as well when it is done. Thanks, Alex

5 20

CloudFlare CAPTCHA Timeout Loop
by teor 11 Oct '16

11 Oct '16

Hi, I'm not sure if this is the best place for CloudFlare-specific bug reports. (I'm happy to direct it to the appropriate channel.) If I have Tor Browser open in High Security level (no JavaScript), and I open a page with a CloudFlare CAPTCHA, and wait a minute or so before answering the CAPTCHA, I see the following message: "Sorry, something went wrong. Please try reloading the page." This error message is also wrong: in order to get the link to work, I need to copy the link, close the tab, and open a new tab with the same link. Using the same tab and hitting reload results in a form resubmission dialog. If the form data is resubmitted, I get the same message, if I say Cancel, I get a blank page. I can imagine this being really frustrating for people who open tabs in the background, and for those whose cognitive or motor functions are slower than expected by the underlying code. (And those who don't understand the workaround of opening the same link in a new tab.) Any chance of getting this fixed as a matter of priority? Tim -- Tim Wilson-Brown twilsonb at mac dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------ T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------

2 1

Re: [tor-access] Specification for bypassing CAPTCHAs using blinded tokens
by Alex Davidson 06 Oct '16

06 Oct '16

>PSS is completely incompatible with blind signatures because the signer >must provide randomness. You could maybe fix this with some sort of cut >& choose or zero knowledge scheme for choosing the randomness, but.. > >All the security proofs for RSA blind signatures just replace PSS with >FDH anyways. In fact, CloudFlare might not need a FDH for verification >because hash factoring attacks sound implausible, but worse.. Yeah this is a mistake in the specification - thanks for pointing it out. We planned to use a FDH hash for this operation. >There is nothing about how the blinding factors get chosen! > >There are absolutely brutal deanonymization attack on blind signatures >where the blinding factor is not created using a full domain PRNG, >probably your FDH for the signature. In this case, I really mean full >domain where you (1) generate a random 2048 bit number, (2) test that >it's less than the RSA modulus n, and (3) throw it away and start again >if it is not. On average, this requires generating two 2048 bit numbers >because n should lie half way between 2^2047 and 2^2048, but obviously a >malicious exchange could pick a small n to make the clients do a bit >more work. I agree that the blinding factors should be chosen carefully and this is something that is currently being built into the extension we're developing. I'll add this explicitly to the document as well as it is an important consideration. Regarding the possibility of a malicious edge using a small modulus n. Given that there will only be one public signing key available at any time and since this will be publicly available (and checked by the clients using the CT log) it will be difficult to get away with this without clients realising. >There are more issues with blind Schnorr signatures, but they look >susceptible to this attack too. The blind BLS signature scheme somes >with different concerns : Thanks for the update on the security of BLS signatures. I haven't thought about these too much and they were added to the spec more as just an afterthought in case we wanted to explore an alternative to RSA. I had a conversation with Filippo a while ago and he mentioned that Tanja thought that going with RSA for now was probably the best idea due to the relative simplicity of the scheme. I'm open to re-engaging in the conversation however and if there are genuine attacks on this scheme then we'd have to consider something else.

2 1

deanonymizaton attacks
by Jeff Burdges 05 Oct '16

05 Oct '16

I've sent a bunch of emails to the tor-access list rather quickly, but just to reiterate the most important part : There are two very serious deanonymizaton attacks in the spec as written so far. First, if one does not use a blinding factor indistinguishable from random that ranges over precisely the domain Z mod n, then you leak 1 bit per token to the mint. Second, if one does not check the GCD of both the hash and the blinding factor* with the RSA modulus n, then one potentially leaks even more bits vs a malicious RSA key made from two bigish primes and several smaller primes. In both case, any leaked bits accumulate as you spend multiple tokens, or via an intersection attack, which quickly deanonymizes users. If one checks out GNUNet's svn repository, then one could find my commits that address these attacks in Taler by running : svn log gnunet/src/util/crypto_rsa.c | less Just wanted to reiterate this to it didn't get buried in all the minor concerns. Jeff * Inversion mod n might catch this on the blinding factor side, but doing it that way might give worse error reporting. p.s. I looked more seriously at blind BLS signatures, seemingly not as bad as I'd feared, although the public key validation issues are likely to remain tougher than one normally expects, especially for this application.

1 0

Re: [tor-access] Predicting effectiveness
by Alex Davidson 04 Oct '16

04 Oct '16

> If this becomes an issue, there is an approach that might work : Just > use multiple signing keys, one system wide key C for all CloudFlare > sites, and individual site keys for each site CloudFlare protects. If > you solve a CAPTCHA then you withdraw a moderate stack of C tokens. If > you visit site X then you spend an X token if you have one, but if you > do not then you spend a single C token to withdraw tens of thousands of > X tokens. So solving a CAPTCHA is worth hundreds of thousands of page > loads, but only across a moderate number of sites. We could've separate > Cbig and Csmall keys such that first it withdraws with Csmall, but if > the users blows through that quickly then it withdraws with Cbig. The spec already accounts for this by giving out a single-domain cookie to any client that successfully redeems a token. We'd need to figure out how long these cookies last for (a day perhaps?), but the idea is that the client would no longer need to redeem any more tokens for that domain. Each token effectively guarantees you access to a resource for the given time period. Because of this we have reduced the number of tokens that should be handed out. For example in the original spec 10,000 tokens were talked about as a reasonable amount whereas in our implementation we use somewhere between 100 and 1000. In our implementation we struggled to work with more than 1000 tokens without rendering the browser complete useless for a fairly long time period anyway, since the extension has to verify and unblind each of the tokens it receives. Alex

1 0