Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#12673 closed enhancement (fixed)

New fte bridges

Reported by: kpdyer Owned by: kpdyer
Priority: Medium Milestone:
Component: Circumvention/Pluggable transport Version:
Severity: Keywords: MikePerry201409R, TorBrowserTeam201409
Cc: gk, asn, mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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!

Child Tickets

Change History (22)

comment:1 Changed 5 years ago by asn

Very nice!

comment:2 Changed 5 years ago by cypherpunks

fte bridges should to tolerate unknown http headers.

comment:3 Changed 5 years ago by kpdyer

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!

Last edited 5 years ago by kpdyer (previous) (diff)

comment:4 Changed 5 years ago by cypherpunks

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\n

No 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\n

comment:5 Changed 5 years ago by kpdyer

cypherpunks: I created a new issue for this discussion, here: https://trac.torproject.org/projects/tor/ticket/12677.

comment:6 Changed 5 years ago by mikeperry

Resolution: fixed
Status: newclosed

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.

comment:7 Changed 5 years ago by 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.
  • Can you remind me why we shouldn't use DNS names in the bridge lines?

-Kevin

comment:8 in reply to:  7 ; Changed 5 years ago by 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.

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

comment:9 in reply to:  8 ; Changed 5 years ago by 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?

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

comment:10 in reply to:  9 ; Changed 5 years ago by mikeperry

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

comment:11 in reply to:  10 Changed 5 years ago by arma

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. It comes down to whether you're using bridges for reachability or for security.

https://blog.torproject.org/blog/different-ways-use-bridge

comment:12 Changed 5 years ago by kpdyer

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.

comment:13 Changed 5 years ago by mikeperry

Keywords: MikePerry201408R TorBrowserTeam201408 added; MikePerry201407R removed
Resolution: fixed
Status: closedreopened

comment:14 Changed 5 years ago by mikeperry

Owner: changed from asn to kpdyer
Status: reopenedassigned

comment:15 Changed 5 years ago by mikeperry

Status: assignedneeds_review

Trac cannot change assignment without resetting ticket state...

comment:16 Changed 5 years ago by kpdyer

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!

comment:17 Changed 5 years ago by mikeperry

Keywords: MikePerry201409R TorBrowserTeam201409 added; MikePerry201408R TorBrowserTeam201408 removed

Have these been tested on an IPv6 client yet? I also don't have IPv6 atm.

comment:18 Changed 5 years ago by kpdyer

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.

comment:19 Changed 5 years ago by kpdyer

Resolution: fixed
Status: needs_reviewclosed

comment:20 Changed 5 years ago by gk

Resolution: fixed
Status: closedreopened

This is not merged yet.

comment:21 Changed 5 years ago by mikeperry

Resolution: fixed
Status: reopenedclosed

Ok, merged for the next alpha (4.0a4). I also separated the IPv6 bridges into their own selection.

This will also make it in the next stable, based on Firefox31esr in mid-October.

comment:22 Changed 5 years ago by kpdyer

Awesome. Thanks!

Good idea on separating out the IPv6 bridges.

Note: See TracTickets for help on using tickets.