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.
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.
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:
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.
--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
>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
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.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 tor-relays Info Page
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org tor-relays Info Page