Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#2576 closed task (wontfix)

Can we try to extend from the bridge to a website and learn if the website is reachable?

Reported by: arma Owned by:
Priority: Medium Milestone:
Component: Metrics/Analysis Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Ticket #1851 suggests reprogramming bridges to connect to baidu periodically, and then report the reachability results in their extrainfo descriptors. We'd have to specify how that reporting works, how often the tests happen, whether we should generalize to write "baidu.com" in the consensus, etc.

A much simpler approach would be to build a circuit to the bridge, extend that circuit to baidu.com:80, and then look at the failure error code and discern whether it was reachable and just didn't TLS right or whether it was unreachable.

Can we manipulate Tor's protocol to learn this? Or is the error code too opaque? If it works, we should whip up a Torflow like thing that checks reachability of baidu from every bridge.

Child Tickets

Change History (11)

comment:1 in reply to:  description ; Changed 10 years ago by rransom

Replying to arma:

Ticket #1851 suggests reprogramming bridges to connect to baidu periodically, and then report the reachability results in their extrainfo descriptors. We'd have to specify how that reporting works, how often the tests happen, whether we should generalize to write "baidu.com" in the consensus, etc.

A much simpler approach would be to build a circuit to the bridge, extend that circuit to baidu.com:80, and then look at the failure error code and discern whether it was reachable and just didn't TLS right or whether it was unreachable.

So Tor bridges, and only Tor bridges, will try to open TLS connections to baidu.com:80? Do I really need to tell you that this is a bad idea?

comment:2 Changed 10 years ago by arma

Component: Tor RelayTor Bridge

comment:3 in reply to:  1 Changed 10 years ago by arma

Replying to rransom:

Replying to arma:

A much simpler approach would be to build a circuit to the bridge, extend that circuit to baidu.com:80, and then look at the failure error code and discern whether it was reachable and just didn't TLS right or whether it was unreachable.

So Tor bridges, and only Tor bridges, will try to open TLS connections to baidu.com:80? Do I really need to tell you that this is a bad idea?

I guess you do. But I don't agree. I want to know if this is as simple to do with our current protocol as I think it might be. I do not accept that learning that answer is a bad idea.

Also, I think you overestimate China's interest in playing the arms race. Unless you can tell me a perfect scalable usable uncensorable design, we will need to make some compromises. Most of these compromises are tradeoffs between blocking-resistance and usability. We need to explore various points in that space. And it's not like our current bridges are all that valuable, so now is a great time to experiment.

comment:4 Changed 9 years ago by nickm

Milestone: Tor: unspecified

comment:5 Changed 9 years ago by arma

Component: Tor BridgeAnalysis

comment:6 Changed 9 years ago by arma

Milestone: Tor: unspecified

comment:7 Changed 9 years ago by rransom

As I mentioned on #3520, all TRUNCATED cells currently result in a CIRC FAILED event with REMOTE_REASON=OR_CONN_CLOSED. That will need to be fixed before we can hope to distinguish between ‘unable to complete TCP handshake’ and ‘opened TCP connection but got wrong TLS handshake/cert’.

comment:8 Changed 9 years ago by runa

Milestone: Sponsor E: March 15, 2012

comment:9 Changed 9 years ago by runa

Milestone: Sponsor E: March 15, 2012

comment:10 Changed 5 years ago by phw

Resolution: wontfix
Severity: Normal
Status: newclosed

At this point, bridges aren't blocked duplex. See, for example https://censorbib.nymity.ch/#Ensafi2015a

Nevertheless, this seems like a fun trick to keep in mind for firewalls that do block both ways.

comment:11 in reply to:  7 Changed 5 years ago by teor

Replying to rransom:

As I mentioned on #3520, all TRUNCATED cells currently result in a CIRC FAILED event with REMOTE_REASON=OR_CONN_CLOSED. That will need to be fixed before we can hope to distinguish between ‘unable to complete TCP handshake’ and ‘opened TCP connection but got wrong TLS handshake/cert’.

Making this change would enable all sorts of port scanning attacks through Tor.

The fact that we don't distinguish between these cases made #8976 much less of a security risk.

Note: See TracTickets for help on using tickets.