Opened 5 years ago

Last modified 5 weeks ago

#12389 needs_revision defect

Should we warn when exit nodes are using opendns or google dns?

Reported by: nickm Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay dns configuration libevent-help
Cc: Actual Points:
Parent ID: Points: small
Reviewer: Sponsor:

Description

Somewhat related to discussion on #8093 -- people are still setting up exit nodes to use OpenDNS or Google DNS. Is that really a safe idea? That makes it distressingly easy for these DNS services (or anybody watching them) to get timing information on user DNS requests.

Furthermore, the default OpenDNS configuration blocks some stuff. If we don't warn about OpenDNS in general, maybe we should warn when configuring an OpenDNS server in a way that hasn't disabled blocking.

Child Tickets

Attachments (2)

0001-Warn-relay-operators-if-they-use-Google-DNS-or-Open-.patch (2.1 KB) - added by gsathya 5 years ago.
Tor patch
0001-Add-evdns_base_is_nameserver_present.patch (2.1 KB) - added by gsathya 5 years ago.
libevent patch

Download all attachments as: .zip

Change History (34)

comment:1 Changed 5 years ago by nickm

Keywords: 026-triaged-1 added

If this info is exposed from evdns, we should do it in 0.2.6.

Changed 5 years ago by gsathya

libevent patch

comment:2 Changed 5 years ago by gsathya

Status: newneeds_review

Attached patches. I've just #ifdef'd this feature for libevent2.0+, not sure what the right approach is. Also, the message needs to be tweaked.

Last edited 5 years ago by gsathya (previous) (diff)

comment:3 Changed 5 years ago by nickm

Status: needs_reviewneeds_revision

It's a good start; let me make a few suggestions.

  • There should be one table; it should probably list stuff like { "8.8.8.8", "Google" }, ...
  • The message should be something more like, "it looks like you're using a public %s nameserver for your Tor exit node. This can be a problem for the network: please see (URL)" and then link to some URL.
  • I think we need to detect whether the function is present using autoconf, and not just check for libevent 2. After all, many libevent 2.0 versions are out there already, without this new function.
  • In the new Libevent function, you extract started_at from the evdns_base before you lock the evdns_base. That's a potential race condition, I think.

comment:4 Changed 4 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final
Status: needs_revisionneeds_review

I've added a function evdns_base_get_nameserver_add() to libevent. 2.1.6-beta should have it.

I've revised the patch to use it in "feature12389". It needs a real URL and a test to see whether the option exists.

comment:5 Changed 4 years ago by Sebastian

I think we shouldn't implement this. I think Google DNS for many people is a sane choice, saner than what their ISP provides by default. Warning people off of it might not make them provide better service as exit relays. It surely is a tradeoff, but in other instances we're happy with the tradeoff (think meek - your bridge is a cdn, just like all the websites you fetch).

Which DNS server to pick is an operational choice by the relay operator, and we don't like telling people what to do in general unless we have a very good reason for it or have a policy on that such behaviour is clearly bad (like modifying content, for example). Why do we pick opendns and google here? Are there others we should pick? Why do we get to decide who is scary and who is not? A counterargument to this is that most people probably don't think about their dns provider at all, so we have a chance to reach them.

I think such a recommendation is best worded as a recommendation with evidence, maybe a blog post or tor-relays posting. Embedding a warning like that into tor makes it - to me - an official torproject policy saying "google dns is bad".

comment:6 Changed 4 years ago by nickm

My counterargument is that for every one exit node operator who has used google dns after a careful consideration of risks and advantages, I bet there is at least one other who never thought about it, and wouldn't read a document full of recommendations if we made one.

If we make the warning phrased right, it will sound advisory rather commanding.

comment:7 in reply to:  6 Changed 4 years ago by cypherpunks

Replying to nickm:

My counterargument is that for every one exit node operator who has used google dns after a careful consideration of risks and advantages, I bet there is at least one other who never thought about it, and wouldn't read a document full of recommendations if we made one.

If we make the warning phrased right, it will sound advisory rather commanding.

Completely agree with Nick here.

comment:8 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:9 Changed 4 years ago by nickm

Status: needs_reviewneeds_revision

This needs work:

  • We need to write (or find) a "picking a dns provider" webpage
  • This code probably needs to become exit-only.
  • The #ifdef needs to check for the presence of evdns_base_get_nameserver_addr.

comment:10 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:11 Changed 4 years ago by nickm

Keywords: 028-triaged added

comment:12 Changed 4 years ago by nickm

Points: small

comment:13 Changed 4 years ago by nickm

(weasel thinks this is a good idea iiuc.)

comment:14 Changed 4 years ago by nickm

Keywords: pre028-patch added

comment:15 Changed 3 years ago by nickm

Owner: set to nickm
Severity: Normal
Status: needs_revisionassigned

Setting nickm as the owner of this needs_revision ticket.

comment:16 Changed 3 years ago by nickm

Status: assignedneeds_revision

comment:17 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

These seem like features, or like other stuff unlikely to be possible this month. Bumping them to 0.2.9

comment:18 Changed 3 years ago by isabela

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

tickets market to be removed from milestone 029

comment:19 Changed 3 years ago by teor

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

Milestone renamed

comment:20 Changed 3 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:21 Changed 2 years ago by yawning

Resolved #21437 as a duplicate.

comment:22 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:23 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:24 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:25 Changed 2 years ago by nickm

Keywords: 027-triaged-1-out removed

comment:26 Changed 2 years ago by nickm

Keywords: 026-triaged-1 removed

comment:27 Changed 2 years ago by nickm

Keywords: 028-triaged removed

comment:28 Changed 2 years ago by nickm

Keywords: pre028-patch removed

comment:29 Changed 2 years ago by nickm

Keywords: dns configuration libevent-help added
Priority: MediumHigh

comment:31 Changed 5 weeks ago by nickm

Owner: nickm deleted
Status: needs_revisionassigned

comment:32 Changed 5 weeks ago by nickm

Status: assignedneeds_revision

None of these revisions are in my near-term plans.

Note: See TracTickets for help on using tickets.