Opened 6 years ago

Last modified 4 days ago

#7349 new project

Obfsbridges should be able to "disable" their ORPort

Reported by: asn Owned by:
Priority: Very High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-bridge, SponsorZ, tor-pt, proposal-needed, censorship, sponsor19, 040-roadmap-proposed
Cc: isis, yawning, cass, mrphs, gk, catalyst, ln5, phoul, dmr Actual Points:
Parent ID: Points: 10
Reviewer: Sponsor:

Description

In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.

We should spec and implement a torrc option that hides the ORPort of obfsbridges.

Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?

Child Tickets

TicketStatusOwnerSummaryComponent
#17159newDeploy the PT reachability tests on some centralised system which reports to BridgeDB/BridgeAuthObfuscation/Pluggable transport

Change History (41)

comment:1 in reply to:  description Changed 6 years ago by arma

Replying to asn:

In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.

We should spec and implement a torrc option that hides the ORPort of obfsbridges.

Suggestions on what to call it?

Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?

I think "bind just to localhost" is a fine default. For people who put their transport somewhere else, they should be able to follow directions (as long as we write said directions and they're not too complex).

This config option should also disable the ORPort reachability testing.

comment:2 Changed 6 years ago by arma

Also, if we disable the ORPort reachability checking, it would probably be wise to replace it with *something* to give feedback to the operator that the obfsproxy port is reachable from the outside world.

comment:3 Changed 6 years ago by arma

Type: taskproject

Also also, Tonga only knows how to test ORPort reachability, and if the ORPort isn't reachable, the bridge won't get the Running line in the consensus that Tonga sends to bridgedb, so bridgedb won't give it out.

And as a third kicker, I expect many of these tools, possibly including Tor, behave poorly when they see a relay descriptor with an ORPort of 0.

This task is worthwhile to do, but it involves many subtasks.

comment:4 Changed 6 years ago by arma

Keywords: SponsorZ added

comment:5 Changed 6 years ago by arma

Keywords: tor-bridge, SponsorZtor-bridge SponsorZ

comment:6 Changed 5 years ago by hsn

This should be ultra high priority since i am loosing bridge game with china firewall. They tend to detect obfs3 as suspicious traffic and then do scan on IP discovering tor bridge.

To make this reliable, not only disabling ORPort is needed but also make shared secret to work with bridgedb distributing it to clients.

As temporary workaround i suggest to make list of IPs which are used for running checks on bridge public, so we can allow them to connect into ORPort but drop other traffic.

comment:7 Changed 4 years ago by asn

Keywords: tor-pt added
Milestone: Tor: unspecifiedTor: 0.2.???

comment:8 Changed 4 years ago by asn

Keywords: proposal-needed added

Proposals will need to be written for this to be possible.

comment:9 Changed 4 years ago by asn

phw suggests some other potential solutions/workarounds:

22:09 < phw> the bridgespa paper solves this on the transport layer: http://www.cypherpunks.ca/~iang/pubs/bridgespa-wpes.pdf however, it's platform dependent.
22:11 < phw> there's also the kernel patch of the TUM people which they wanted to get into upstream.

comment:10 Changed 4 years ago by isis

Cc: isis added

comment:11 Changed 3 years ago by isis

Owner: set to isis
Status: newassigned

I think I would like to work on this soon, hopefully in time to make it into 0.2.8. Feel free to take it from me if I haven't updated this ticket and you'd like to work on it.

comment:12 Changed 3 years ago by elypter

why not ditch the orport alltogether. if all relays communicate over pluggable transports then active probing will become obsolete.

Last edited 3 years ago by elypter (previous) (diff)

comment:13 in reply to:  12 ; Changed 3 years ago by isis

Replying to elypter:

why not ditch the orport alltogether. if all relays communicate over pluggable transports then active probing will become obsolete.

This is about making the ORPort "ditchable". However, it is not about making bridges communicate to the next hop over PTs, since that would reveal that they are a bridge (and thus nullify most of the work I did for #7144).

comment:14 Changed 3 years ago by isis

Keywords: 028-triage added

comment:15 Changed 3 years ago by isis

Priority: normalmajor

I'm upping the priority because I feel that this is the next major defense (that is currently feasible) for protecting bridges against enumeration.

comment:16 Changed 3 years ago by isis

Points: 9000+

Adding over nine thousand points, meaning something like "The size of this ticket is large and will require more than one week of work."

In actuality, I estimate this will take a month (or possibly more) work, once the following (prerequisite) tasks are factored in:

  • Discuss other ways for the BridgeAuth to conduct reachability testing (#5211, #13589?; related to #7144 anti-enumeration defenses and prop#188).
  • Write a proposal for this ticket.
  • Probably deploy something like #6396 on BridgeDB or some other centralised system which reports to BridgeDB/BridgeAuth. We'd also need to be able to do bridge bandwidth testing over PTs, since the ORPort would be gone. (#17159)
  • Hack on this ticket.
  • Revise various specs/proposals.
  • Review changes, rinse, repeat.
  • Merge.
Last edited 3 years ago by isis (previous) (diff)

comment:17 Changed 3 years ago by isis

Also, we should evaluate which tools might break if the ORPort is advertised as 0 for a bridge. Potentially affected tools which I can think of: Stem, Metrics, Onionoo, Globe, Atlas… (any more?)

comment:18 Changed 3 years ago by yawning

Cc: yawning added

comment:19 in reply to:  13 ; Changed 3 years ago by yawning

Replying to isis:

Replying to elypter:

why not ditch the orport alltogether. if all relays communicate over pluggable transports then active probing will become obsolete.

This is about making the ORPort "ditchable". However, it is not about making bridges communicate to the next hop over PTs, since that would reveal that they are a bridge (and thus nullify most of the work I did for #7144).

It's also pointless extra overhead, unless we're talking about using a PT protocol instead of TLS. At the moment this would be a horrible idea because the closest thing to a PT protocol that provides the reuired security properties is obfs4, and it wasn't designed as a TLS replacement.

comment:20 in reply to:  19 Changed 3 years ago by elypter

Replying to isis:

This is about making the ORPort "ditchable". However, it is not about making bridges communicate to the next hop over PTs, since that would reveal that they are a bridge (and thus nullify most of the work I did for #7144).

when i wrote this ia assumd that pluggable transports are being used that require a pass code so that active pobing would only be possible if the attacker already knows the bridge. a bridge guard only adds additional (bridge)security just like with a disabled or port.

Replying to yawning:

pointless extra overhead

in the current state of western governments yes, tor is kind of tolerated but the ice is middle thick. however trusting in the status quo of the internet seems to be a rather risky security model in long term. there doesnt even have to be an evil government censor overlord. it could be enough if isps throttle down tor connections for "traffic optimization" and the goverment looks away. and yes ips are still public but there is not only a technical side to censorship there is also a legal one especially in democracies. ratelimiting or blocking specific pattern shapes might be perfectly legal while blocking ips is not.
"ditching or port alltogether" was a bit provocative.
what i wanted to promote was that the nodes should be able to choose their transport freely so the network can adapt to its environment.

comment:21 Changed 2 years ago by cass

Cc: cass added
Severity: Normal

This ticket is marked as high priority, but it looks like progress stalled a year ago. Is this still an active issue that needs funding?

comment:22 Changed 2 years ago by arma

Yes, I believe this is still an active issue that is important to do, and funding would make it so developers can pay attention to it. It's a good fit for a censorship circumvention funding proposal, and it's the sort of thing that the network team should be (or become) good at doing.

Basically, the effect of the current situation is that we can have all sorts of fancy pluggable transports that are hard to detect, but all bridges(*) offer an easy way (ok, maybe more like a not-all-that-hard way) to verify that they're a bridge, by trying to find its ORPort and then just talking the vanilla Tor protocol to it and see if it responds like a Tor bridge. The reason we're in this pickle is that all of our "is it running" infrastructure is set up to look at the ORPort, so if we make the ORPort unreachable from the outside, we need to fix all these other things. (isis has a good start to a list, and I think she's right that it will take a good chunk of energy to do them all well.)

(*) It isn't quite all bridges. The ones that we ship by default in the Tor Browser don't need to have any of these reachability tests work, since we basically tell clients in the Tor Browser that they're always up and working. The bridge operator can also set AssumeReachable 1 in her torrc config file, and then firewall the port, and I bet that would work, but it isn't the sort of thing every bridge operator will be able to do.

comment:23 Changed 2 years ago by mrphs

Cc: mrphs added

comment:24 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:25 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:26 Changed 22 months ago by gk

Cc: gk added

comment:27 Changed 18 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:28 Changed 18 months ago by nickm

Keywords: 028-triage removed

comment:29 Changed 18 months ago by nickm

Keywords: censorship added
Points: 9000+10
Priority: HighVery High

comment:30 Changed 14 months ago by catalyst

Cc: catalyst added
Sponsor: SponsorM-can

comment:31 Changed 9 months ago by ln5

Cc: ln5 added

comment:32 Changed 6 months ago by arma

Keywords: 035-proposed added

comment:33 Changed 5 months ago by phoul

Cc: phoul added

comment:34 Changed 5 months ago by dmr

Cc: dmr added

comment:35 Changed 5 months ago by isis

Owner: isis deleted

comment:36 Changed 4 months ago by nickm

Keywords: 035-roadmap-proposed added; 035-proposed removed

comment:37 Changed 4 months ago by teor

Status: assignednew

Make everything that is assigned to no-one new again.

comment:38 Changed 3 weeks ago by arma

Keywords: sponsor19 added
Sponsor: SponsorM-canSponsor19

comment:39 Changed 3 weeks ago by arma

Sponsor: Sponsor19

comment:40 Changed 3 weeks ago by teor

Keywords: 036-roadmap-proposed added; 035-roadmap-proposed removed

Move likely enhancements from 035-roadmap-proposed to 036-roadmap-proposed

comment:41 Changed 4 days ago by teor

Keywords: 040-roadmap-proposed added; 036-roadmap-proposed removed

0.3.6 is now 0.4.0: changing roadmap keywords

Note: See TracTickets for help on using tickets.