[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?

2 Likes

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

1 Like

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:

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] doc/moat.md · main · The Tor Project / Anti-censorship / rdsys · GitLab

···

--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.

1 Like

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

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like