Opened 3 years ago

Last modified 12 days ago

#17193 assigned defect

Don't print bridge IPs/fingerprints in WARN/NOTICE log messages

Reported by: isis Owned by: isis
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Major Keywords: tor-bridge, 034-triage-20180328, 034-removed-20180328
Cc: isis Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor: SponsorM

Description

By default, we currently print out bridge IP:ports and fingerprints in tor's log messages at the notice and warn levels. Users often copy+paste these logs to various public places when trying to debug why their connection isn't working.

I understand that this is probably useful information to give to the support desk for debugging why tor isn't working… but would it be doable to have the support people ask, "Hey could you add SafeLogging 0 to your torrc?" or something?

I think the default should be to sanitise bridge IP:ports and fingerprints at these levels.

Child Tickets

Change History (26)

comment:1 Changed 3 years ago by isis

I'm willing to take this ticket (and the changes should be trivial), if we think that doing this is a good idea.

comment:2 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-final

I think these can should be covered by safelog, yeah.

comment:3 Changed 3 years ago by isis

Owner: set to isis
Status: newassigned

I'm not decided yet on whether to safelog the bridge's fingerprint or use the bridge's hashed fingerprint. I guess I'll decide when I get around to doing this ticket.

comment:4 Changed 3 years ago by arma

It seems wise to check with the support folks, e.g. Colin and Nima, about whether this interaction actually happens with them. "Just add this line to your torrc" is an impossible step for most users, especially now that Tor Browser hides your torrc file so well.

(I don't see "sometimes users share their bridges" as that big a deal, in that without help those people are going to become non-users anyway.)

comment:5 Changed 3 years ago by nickm

Points: small/medium

comment:6 Changed 3 years ago by isis

Could be fixed at the same time at #7457, perhaps. It's the same lines of code at least.

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

Sponsor: SponsorS-can

Tagging these bridge- and PT- items as S-can.

comment:9 Changed 2 years ago by nickm

Keywords: tor-bridge 028-triagetor-bridge, 028-triage

comment:10 Changed 23 months ago by nickm

Points: small/medium2

small/medium => 2.

comment:11 Changed 21 months ago by isis

Keywords: TorCoreTeam201608 added

Adding to my august tickets.

comment:12 Changed 20 months ago by isis

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

Defer some of my 029 tickets to 030

comment:13 Changed 15 months ago by nickm

Milestone: Tor: 0.3.0.x-finalTor: 0.3.1.x-final

Deferring these to 0.3.1.x as nonbugfixes.

comment:14 Changed 14 months ago by nickm

Sponsor: SponsorS-can

Clear sponsorS and sponsorU from open tickets in 0.3.1

comment:15 Changed 12 months ago by isis

Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

Deferring to 0.3.2

comment:16 Changed 11 months ago by nickm

Keywords: 028-triage removed

comment:17 Changed 11 months ago by nickm

Keywords: TorCoreTeam201608 removed

comment:18 Changed 6 months ago by nickm

Severity: Blocker
Sponsor: SponsorM

comment:19 Changed 6 months ago by nickm

Severity: BlockerMajor

comment:20 Changed 3 months ago by arma

I'm still not clear that this one is worth it. Individual bridge addresses are not that precious (so the downside of including details about them in logs which are generally not shared is limited), and the benefits to users of having useful log lines, for those relatively advanced users who know how to find their log lines, seems like a somewhat useful upside.

comment:21 Changed 3 months ago by arma

Looks like the same ticket as #18491 ?

comment:22 Changed 3 months ago by ln5

Doesn't IP addresses to first hops risk incriminating a person linked to a lost laptop or mobile containing this data?

comment:23 Changed 8 weeks ago by teor

Milestone: Tor: 0.3.2.x-finalTor: 0.3.4.x-final

These feature and bugfix tickets have no patches. The earliest they will get done is 0.3.4.

comment:24 Changed 3 weeks ago by nickm

Keywords: 034-triage-20180328 added

comment:25 Changed 3 weeks ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:26 Changed 12 days ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Note: See TracTickets for help on using tickets.