Opened 5 years ago

Last modified 21 months ago

#11973 new defect

Should relays stop making unencrypted directory connections?

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-design tor-relay directory-protocol needs-proposal
Cc: bburley, dcole, arma, ilf@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Continuing a discussion from #11469 :

There is a case to be made that relays should stop uploading and downloading directory information via HTTP. We should consider the arguments there and see if there's a good rationale beyond the standard "why not encrypt everything" baseline.

(To be clear, bridges don't make connections over HTTP.)

Child Tickets

Change History (18)

comment:1 Changed 5 years ago by nickm

From that ticket, my impression of why you'd do a DirPort connection from non-bridge relays:

I think the original rationale was that:

  • all of this information was publicly associated with the uploading IP, and as such encrypting it wouldn't actually protect anything.
  • using a separate port for uploads would allow directory authorities to throttle downloads without harming uploads.

Roger added:

Clients use begindir so it's harder to fingerprint and prevent their directory fetches.

Relays don't use begindir to avoid loading down the directory authorities with ssl handshakes (heavyweight) simply for an http directory publish/fetch (lightweight).

Load on directory authorities seems like it should come primarily from a) clients that are bootstrapping, though we're hoping to resolve that bottleneck with the fallback directory mirrors, and b) relays. It'd be a shame to magnify part 'b' by a lot.

At one point, I thought that b) was spurious, since bug #11469 had turned off direct connections for (most) relays, but Roger pointed out to me that it only turned off direct connections for publishing, and that relays downloading from authorities (which is much more expensive) still use HTTP.

comment:2 Changed 5 years ago by bburley

I have a better understanding now of the reasoning behind using direct or encrypted sessions when communicating with the authorities. (1) Cost of server resources, and (2) protecting information believed to not need protecting.

I don't know the value of (1), but I do believe that removing an additional way of someone determining you are operating as part of the Tor infrastructure in valuable. Yes, someone can enumerate the Tor infrastructure by installing a client. That is one way to get information if they are looking for who is running Tor nodes. Someone trying to figure out what a particular server is running, not looking for Tor specifically, is a different attack/angle. Not encrypting that info allows someone to determine a server is running Tor when they weren't looking for it in the first place, but now they know.

Would it be reasonable have an option created to turn this capability on/off?

comment:3 Changed 5 years ago by teor

Similar to some other options, we could create both a consensus parameter and a torrc option.
The torrc default, auto, would be to use the consensus value, but the torrc option would also allow explicit require SSL/prefer SSL/prefer HTTP/require HTTP (or whatever preference set is considered reasonable).

The consensus parameter would then allow us to turn HTTPS directories on and off depending on the impact on the network.

Would we need separate upload SSL and download SSL parameters, or do we just need a download parameter?

comment:4 Changed 4 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.7.x-final

Worth looking at during 0.2.7 triage IMO

comment:5 Changed 4 years ago by nickm

Status: newassigned

comment:6 Changed 4 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:7 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:8 Changed 3 years ago by teor

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

Milestone renamed

comment:9 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:10 Changed 2 years ago by arma

Severity: Normal

I closed #4130 as a duplicate of this ticket.

comment:11 in reply to:  1 Changed 2 years ago by arma

Replying to nickm:

I think the original rationale was that:

[...]

  • using a separate port for uploads would allow directory authorities to throttle downloads without harming uploads.

For historical context: relays and clients didn't start out using separate ports. It started out that all directory stuff, for everybody, used the DirPort. Then we moved clients over to the ORPort, because they were getting censored by DPI. We decided not to move relays over at the time.

comment:12 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:13 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:14 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:15 Changed 2 years ago by nickm

Keywords: 027-triaged-1-out removed

comment:16 Changed 2 years ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

comment:17 Changed 2 years ago by nickm

Keywords: needs-design tor-relay directory-protocol added

comment:18 Changed 21 months ago by ilf

Cc: ilf@… added
Note: See TracTickets for help on using tickets.