Opened 8 years ago

Last modified 2 years ago

#3566 new enhancement

Should controller events respect SafeLogging 1 torrc option?

Reported by: tornewbie Owned by: chiiph
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, needs-design, intro, safelogging
Cc: Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor:


Vidalia seems not to scrub addresses ignoring SafeLogging directive set in the torrc config file : the first one is the event logged by Vidalia , the second one is the same event logged by Tor while pulling tor git tree with tsocks ( 'usewithtor git pull' on the command line )

[...same time...] Potentially Dangerous Connection! - One of your applications established a connection through Tor to "" using a protocol that may leak information about your destination. Please ensure you configure your applications to use only SOCKS4a or SOCKS5 with remote hostname resolution.

...same time... [warn] Your application (using socks5 to port 9418) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead. For more information, please see

Child Tickets

Change History (12)

comment:1 Changed 8 years ago by arma

Component: VidaliaTor Client
Milestone: Tor: 0.2.3.x-final
Summary: Vidalia should respect SafeLogging 1 torrc optionShould controller events respect SafeLogging 1 torrc option?

(Redirecting to the 'Tor client' component so Nick will look at it too.)

log_unsafe_socks_warning() in src/or/buffers.c is the function in question. The reason Vidalia gets the address and port is because this isn't actually a "log" from Tor's perspective -- it's a controller event:

                              "DANGEROUS_SOCKS PROTOCOL=SOCKS%d ADDRESS=%s:%d",
                              socks_protocol, address, (int)port);

So one option would be for Tor to just send "[scrubbed]" instead of address in its status events. That would seem to be simpler than trying to teach Vidalia which arguments to which events are dangerous to put on the screen.

It might be that Vidalia wants a checkbox in its message log gui to let the user decide whether Tor should have safelogging on or off.

I guess the follow-on question is: are controllers expected to do anything else with these events besides display them to the screen? I can imagine a controller that hunts around in netstat or something to give you more details; and it would be a shame if it had to turn Tor's safelogging off across the board in order to learn the address from the status event.

comment:2 Changed 8 years ago by atagar

For arm's part I scrapes NOTICE, NEWDESC, NS, and NEWCONSENSUS for information. Also, replacing ip address/port entries might break the scraping done by torctl (ie, stack traces when listening for those events).

That said, controllers should be working around this so I'd say definitely go with the first proposed fix (sending "[scrubbed]" to controllers)... just be aware that tor might not be the only thing that needs to change.

Cheers! -Damian

comment:3 Changed 8 years ago by nickm

IMO if we're going to do anything here, the right interface is probably an additional option that says which safelogging options apply to controller events.

comment:4 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final
Type: defectenhancement

Calling this a feature.

comment:5 Changed 7 years ago by nickm

Keywords: tor-client added

comment:6 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:7 Changed 6 years ago by nickm

Keywords: needs-design added
Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:8 Changed 5 years ago by nickm

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

comment:9 Changed 3 years ago by teor

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

Milestone renamed

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

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:12 Changed 2 years ago by nickm

Keywords: intro safelogging added
Points: 5
Priority: MediumLow
Severity: Normal

This is a lot of underlying work, and would take you all over the controller protocol and the stuff that call it, to find things that need to get wrapped with the safelogging wrappers. It would also need widespread but shallow revision to the controller specification.

Note: See TracTickets for help on using tickets.