Should relays stop making unencrypted directory connections?

Continuing a discussion from #11469 (moved) :

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

changed milestone to %Tor: unspecified

added component::core tor/tor directory-protocol milestone::Tor: unspecified needs-design needs-proposal priority::medium severity::normal status::new tor-relay type::defect labels

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

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?

Trac:
Username: bburley

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?

Worth looking at during 0.2.7 triage IMO

Trac:
Milestone: Tor: unspecified to Tor: 0.2.7.x-final

Trac:
Status: new to assigned

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

Trac:
Keywords: N/A deleted, 027-triaged-1-out added

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

Trac:
Milestone: Tor: 0.2.7.x-final to Tor: 0.2.???

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

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

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

I closed #4130 (moved) as a duplicate of this ticket.

Trac:
Reviewer: N/A to N/A
Sponsor: N/A to N/A
Severity: N/A to Normal

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.

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: N/A deleted, 027-triaged-in added

Trac:
Keywords: 027-triaged-in deleted, N/A added

Trac:
Keywords: 027-triaged-1-out deleted, N/A added

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

Trac:
Status: assigned to new

Trac:
Keywords: needs-proposal deleted, needs-design tor-relay directory-protocol needs-proposal added

Trac:
Username: ilf
Cc: bburley, dcole, arma to bburley, dcole, arma, ilf@zeromail.org

teor and I discussed this ticket more today, and one useful way forward was to simplify the current behavior, by having relays only use the DirPort when they're talking to a directory authority. (Right now relays mostly talk to dir auths, but there are some edge cases where they don't, and that complexifies all the analysis.)

moved to tpo/core/tor#11973 (moved)