New fte bridges
I've increased the breadth of fte bridges.
https://github.com/kpdyer/tor-browser-bundle/commit/b1b863534b25a6c95b0a5eac76f8cb8be6266f88
We now have a mix of bridges on port 80 and 8080. A mix of IPv4 and IPv6. A mix of IP addresses and DNS names.
Unless you have objections, please merge!
Activity
cypherpunks: If you have a specific use case for fte that it doesn't support, please raise an issue on github: https://github.com/kpdyer/fteproxy. Thanks!
please raise an issue on github it req signup.
specific use case for fte that it doesn't support fte bridge doesn't support anything else than
GET /<encoded_data> HTTP/1.1\r\n \r\nNo any headers, not even different http version.
It hangs on request with normal headers.
GET /<encoded_data> HTTP/1.1\r\n Host: tpo.org\r\n User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0\r\n Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip, deflate\r\n Connection: keep-alive\r\n \r\ncypherpunks: I created a new issue for this discussion, here: https://trac.torproject.org/projects/tor/ticket/12677.
This got merged with the other version bump merge for FTE that gk did. However, I still do not think we should have any DNS names in the bridge lines. I also think that the user should be presented with a choice for IPv6 as a separate option for now, because users who do have IPv6 should have the ability to avoid hitting any IPv4 addresses. Ideally, we would ask the OS somehow if IPv6 worked, and do this sub-selection automatically for the user, but until we figure that out, they should be given the explicit choice IMO.
I have made these changes here: https://gitweb.torproject.org/builders/tor-browser-bundle.git/commitdiff/ecd19a6a88058dedb1726747eb4184a959d5af6b
If you disagree for any reason, let me know. These changes will go out in 3.6.3 and 4.0-alpha-1 unless someone objects or it breaks for some reason.
Trac:
Resolution: N/A to fixed
Status: new to closed-
Replying to kpdyer:
Hi Mike,
- If we can't use DNS, we'll need to remove the IPv6 bridge for now. That was using DNS load balancing on AWS, and there's no guarantee that the IPv6 address will stay the same.
Hrmm. If there is no way to get a fixed IPv6 IP, then we'll have to remove the lines. This is a shame, though, because IPv6 is pretty much completely uncensored everywhere, afaik.
- Can you remind me why we shouldn't use DNS names in the bridge lines?
Because the DNS resolution happens outside of Tor before it has a circuit. This means that it is both a blocking point for the adversary (who might even be able to use their existing IPv4 DNS censorship infrastructure to block the resolution, depending on how DNS is configured on the client), as well as a clear signal that Tor is in use by that client, since it is cleartext.
Replying to mikeperry:
Replying to kpdyer:
Hi Mike,
- If we can't use DNS, we'll need to remove the IPv6 bridge for now. That was using DNS load balancing on AWS, and there's no guarantee that the IPv6 address will stay the same.
Hrmm. If there is no way to get a fixed IPv6 IP, then we'll have to remove the lines. This is a shame, though, because IPv6 is pretty much completely uncensored everywhere, afaik.
I could find another provider that can host an IPv6 fte bridge. How much time do I have before the next tag+release?
- Can you remind me why we shouldn't use DNS names in the bridge lines?
Because the DNS resolution happens outside of Tor before it has a circuit. This means that it is both a blocking point for the adversary (who might even be able to use their existing IPv4 DNS censorship infrastructure to block the resolution, depending on how DNS is configured on the client), as well as a clear signal that Tor is in use by that client, since it is cleartext.
It's not clear to me why this is worse, if we have DNS bridges in addition to hard-coded bridges.
Do you mind if I bring this discussion to tor-dev?
-
Replying to kpdyer:
Replying to mikeperry:
Replying to kpdyer:
Hi Mike,
- If we can't use DNS, we'll need to remove the IPv6 bridge for now. That was using DNS load balancing on AWS, and there's no guarantee that the IPv6 address will stay the same.
Hrmm. If there is no way to get a fixed IPv6 IP, then we'll have to remove the lines. This is a shame, though, because IPv6 is pretty much completely uncensored everywhere, afaik.
I could find another provider that can host an IPv6 fte bridge. How much time do I have before the next tag+release?
I will merge an IPv6 bridge as soon as you have it. Who knows when our next release will be, though. Anywhere between 1 day and 5 weeks from now.
- Can you remind me why we shouldn't use DNS names in the bridge lines?
Because the DNS resolution happens outside of Tor before it has a circuit. This means that it is both a blocking point for the adversary (who might even be able to use their existing IPv4 DNS censorship infrastructure to block the resolution, depending on how DNS is configured on the client), as well as a clear signal that Tor is in use by that client, since it is cleartext.
It's not clear to me why this is worse, if we have DNS bridges in addition to hard-coded bridges.
From my POV, DNS doesn't add anything, and seems to introduce new risks and blocking points, especially for IPv6.
Do you mind if I bring this discussion to tor-dev?
Sure, go ahead. It might be useful to get a second opinion on this, especially if you believe that DNS improves our blocking resistance somehow (which I also do not see how it would).
Replying to mikeperry:
Replying to kpdyer:
It's not clear to me why this is worse, if we have DNS bridges in addition to hard-coded bridges.
From my POV, DNS doesn't add anything, and seems to introduce new risks and blocking points, especially for IPv6.
Sounds related to #10801 (moved). It comes down to whether you're using bridges for reachability or for security.
I've added two new IPv4/IPv6 bridges, with static IPs. See:
https://github.com/kpdyer/tor-browser-bundle/commit/a8e337294915a758864c3b969fd01d654078aba2
I'll consider DNS-based bridges over the next couple weeks.
Can someone confirm that I've the right notation for IPv6 bridge addresses? I'm on a non-IPv6-enabled connection, atm.
I've updated the FTE bridges again to remove one that's no longer active:
https://github.com/kpdyer/tor-browser-bundle/commit/4ef6213057d4d1c7bb061055a6441f03ecc4b966
Please merge all changes upstream, when possible!
Tested and confirmed that
https://github.com/kpdyer/tor-browser-bundle/blob/master/Bundle-Data/PTConfigs/bridge_prefs.js
has the latest working FTE bridges. IPv6 bridges are confirmed to be working with IPv6 clients.
