Opened 3 months ago

Closed 4 weeks ago

#23637 closed enhancement (fixed)

Make exit flag depend on ports 80 and 443, not 6667

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In the discussion around #22820, we decided that giving the exit flag to relays that exit to ports 80 and 443 is the right thing to do:

First, port 6667 used to be relevant, but now, and especially with the advent of ircs, it isn't.

Second, we invented the current algorithm for the Exit flag back before Mike invented the 'reduced exit policy'.

Third, a relay that exits to 443 but not 80, or 80 but not 443, is going to make web browsing super bumpy when used with Tor Browser's tab isolation strategy.

So we should simplify it.

Child Tickets

Change History (10)

comment:1 Changed 3 months ago by arma

Status: newneeds_review

My ticket23637 branch implements this change.

moria1 is now running this branch.

https://consensus-health.torproject.org/#overlap made me realize a side effect of this branch: we will decrease the total capacity that the network weights think are on Exits, thus making Exit capacity even more scarce in the network. But I call that a feature, since the exit capacity *is* more scarce in the network, it's just that we're only now realizing it.

comment:2 Changed 3 months ago by arma

And the ticket23637-spec branch in my torspec updates dir-spec.txt.

comment:3 Changed 3 months ago by cypherpunks

If your intent is to make 80 and 443 mandatory anyways, then this branch is ok. But if there are exits that don't want to pass insecure connections (using 443 and 6667 as a workaround), you'll push them off.

comment:4 in reply to:  3 ; Changed 3 months ago by arma

Replying to cypherpunks:

if there are exits that don't want to pass insecure connections (using 443 and 6667 as a workaround)

The trouble is that using 443 and 6667 *isn't* a workaround. For clients who browse the web using both 80 and 443, if they get an exit that only does 443, they need to get a second exit that does 80, for that same interaction. Suddenly they have way more exposure for that interaction than they needed to have.

Pointing back to #22820: the main effect of the Exit flag is to help with load balancing. It makes clients choose that relay less (currently never) for non-exit positions in their circuits. Whereas the presence or absence of the Exit flag *doesn't* prevent clients from building circuits that exit from that relay -- that choice depends on the streams that the client is trying to handle, and the exit policy of each relay they're considering.

comment:5 in reply to:  4 Changed 3 months ago by cypherpunks

Replying to arma:

Replying to cypherpunks:

if there are exits that don't want to pass insecure connections (using 443 and 6667 as a workaround)

The trouble is that using 443 and 6667 *isn't* a workaround.

It is. For exits, of course. While "443 and 6697" is not available.

For clients who browse the web using both 80 and 443, if they get an exit that only does 443, they need to get a second exit that does 80, for that same interaction. Suddenly they have way more exposure for that interaction than they needed to have.

This is a mixed content case. That's why MCB was activated in TBB. Users are explicitly warned about passive/active insecure content on secure webpages. More exposure of the client is far less dangerous than more exposure of the exit to ISP and others.

Pointing back to #22820: the main effect of the Exit flag is to help with load balancing. It makes clients choose that relay less (currently never) for non-exit positions in their circuits. Whereas the presence or absence of the Exit flag *doesn't* prevent clients from building circuits that exit from that relay -- that choice depends on the streams that the client is trying to handle, and the exit policy of each relay they're considering.

And you want more exits to be used for non-exit positions, don't you?

comment:6 Changed 3 months ago by nickm

Milestone: Tor: 0.3.3.x-final

comment:7 Changed 7 weeks ago by nickm

Keywords: review-group-24 added

review-group-24 is now open.

comment:8 Changed 7 weeks ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: 0.3.2.x-final
Status: needs_reviewmerge_ready

taking in master, marking for possible backport.

comment:9 Changed 7 weeks ago by nickm

Keywords: review-group-24 removed

comment:10 Changed 4 weeks ago by nickm

Resolution: fixed
Status: merge_readyclosed

Backporting to 0.3.2 but no further.

Note: See TracTickets for help on using tickets.