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.toradin@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

Quoting elise.toradin@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... -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.