Re: [tor-relays] We need much more bridges with obfs4 and iat-mode set to 1 or 2..barely can't find any.
Philipp Winter regarding iat mode: >The feature introduces a substantial performance penalty for a dubious >and poorly understood privacy gain. If I were to write an algorithm to >detect obfs4, I wouldn't bother dealing with its flow properties; there >are easier ways to identify the protocol. In hindsight, it was >probably >a mistake to expose the iat option to users and bridge operators. > >Cheers, >Philipp https://lists.torproject.org/pipermail/tor-relays/2021-February/019370.html On 8/24/22 09:50, John Csuti via tor-relays wrote: I can dedicate 2 more IP’s from my network to this. You just want it to be obfs4 and iat-mode set to 2? Thanks, John C. On Aug 24, 2022, at 2:35 AM, elise.tora...@web.de wrote: As in the title, it took me over an hour to find one - for my security requirements, the timing and sometimes, packet size obfuscation, is very important. Now this might sound a bit like sarcasm, but I also think that we should harden the https://bridges.torproject.org page, just a captcha and not delivering new bridges to the same IP is a bit weak, in my opinion. Perhaps extend that block to an entire /16 range, or require some computational power to be used up (could be easily implemented in JavaScript) first. The last suggestion would also eliminate bots that scrape bridge addresses using plaintext clients entirely, at least until someone builds a chromium / (insert arbitrary browser engine here) bot. I know this is a cat and mouse game, but the bridge page should be as secure as possible. For example: I wouldn't mind waiting 5-15 minutes to get a list of 3 bridges (optionally, with a button that says, iat-mode non-zero only, but we need to harden more before implementing something like that), some government agencies might be thrown off by this, along with the fact that they also only have limited IP ranges. Thoughts? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] We need much more bridges with obfs4 and iat-mode set to 1 or 2..barely can't find any.
Quoting elise.tora...@web.de (2022-08-23 18:39:08) >As in the title, it took me over an hour to find one - for my security >requirements, the timing and sometimes, packet size obfuscation, is very >important. AFAIK there is no evidence that iat-mode 1 or 2 provides more security, that is why we recommend setting bridges with iat-mode=0. >Now this might sound a bit like sarcasm, but I also think that we should >harden the https://bridges.torproject.org page, just a captcha and not >delivering new bridges to the same IP is a bit weak, in my opinion. > >Perhaps extend that block to an entire /16 range, or require some >computational power to be used up (could be easily implemented in >JavaScript) first. > >The last suggestion would also eliminate bots that scrape bridge addresses >using plaintext clients entirely, at least until someone builds a chromium >/ (insert arbitrary browser engine here) bot. > >I know this is a cat and mouse game, but the bridge page should be as >secure as possible. > >For example: I wouldn't mind waiting 5-15 minutes to get a list of 3 >bridges (optionally, with a button that says, iat-mode non-zero only, but >we need to harden more before implementing something like that), some >government agencies might be thrown off by this, along with the fact that >they also only have limited IP ranges. I agree with you, patches are welcome: https://gitlab.torproject.org/tpo/anti-censorship/bridgedb We use different bridges for each distribution mechanism, and different protections. We know the captcha is not enough, that is why in other distributors we use other mechanisms[0]. Our experience is that censors focus more on discovering moat bridges (the ones distributed directly to the tor browser), and the bridges distributed directly on the web don't get that much censored, that is why we don't put much effort on improving the https distributor. But as I said you are welcome to work on it. [0] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] We need much more bridges with obfs4 and iat-mode set to 1 or 2..barely can't find any.
I can dedicate 2 more IP’s from my network to this. You just want it to be obfs4 and iat-mode set to 2? Thanks, John C. > On Aug 24, 2022, at 2:35 AM, elise.tora...@web.de wrote: > > > As in the title, it took me over an hour to find one - for my security > requirements, the timing and sometimes, packet size obfuscation, is very > important. > > Now this might sound a bit like sarcasm, but I also think that we should > harden the https://bridges.torproject.org page, just a captcha and not > delivering new bridges to the same IP is a bit weak, in my opinion. > > Perhaps extend that block to an entire /16 range, or require some > computational power to be used up (could be easily implemented in JavaScript) > first. > > The last suggestion would also eliminate bots that scrape bridge addresses > using plaintext clients entirely, at least until someone builds a chromium / > (insert arbitrary browser engine here) bot. > > I know this is a cat and mouse game, but the bridge page should be as secure > as possible. > > For example: I wouldn't mind waiting 5-15 minutes to get a list of 3 bridges > (optionally, with a button that says, iat-mode non-zero only, but we need to > harden more before implementing something like that), some government > agencies might be thrown off by this, along with the fact that they also only > have limited IP ranges. > > Thoughts? > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] We need much more bridges with obfs4 and iat-mode set to 1 or 2..barely can't find any.
As in the title, it took me over an hour to find one - for my security requirements, the timing and sometimes, packet size obfuscation, is very important. Now this might sound a bit like sarcasm, but I also think that we should harden the https://bridges.torproject.org page, just a captcha and not delivering new bridges to the same IP is a bit weak, in my opinion. Perhaps extend that block to an entire /16 range, or require some computational power to be used up (could be easily implemented in _javascript_) first. The last suggestion would also eliminate bots that scrape bridge addresses using plaintext clients entirely, at least until someone builds a chromium / (insert arbitrary browser engine here) bot. I know this is a cat and mouse game, but the bridge page should be as secure as possible. For example: I wouldn't mind waiting 5-15 minutes to get a list of 3 bridges (optionally, with a button that says, iat-mode non-zero only, but we need to harden more before implementing something like that), some government agencies might be thrown off by this, along with the fact that they also only have limited IP ranges. Thoughts? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
