[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #15161 [Applications/Tor Messenger]: CTCP fingerprinting
#15161: CTCP fingerprinting
----------------------------------------+--------------------------
Reporter: cypherpunks | Owner: sukhbir
Type: defect | Status: reopened
Priority: Immediate | Milestone:
Component: Applications/Tor Messenger | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
----------------------------------------+--------------------------
Comment (by cypherpunks):
Replying to [comment:15 cypherpunks]:
> Why not to remove ctcp responses completely (but act on them to
indicating that someone is probing the user)? In fact it is not needed for
operation. I was very surprised that it discloses local time which can
easily be used for deanonimization using clock drift and/or giving unique
time to each client from public NTP servers.
Removing CTCP support completely is a bad idea. Many IRC servers rely on
VERSION support in order to expose features to the user. Additionally,
some channels may have bots that CTCP you when you join, and kick you if
your client does not respond. If there is no CTCP VERSION support, this
client would be additionally breaking the agreements of several large
public IRC servers, like Rizon.
VERSION can be implemented without jeopardizing anonymity. PING is another
important CTCP request which I don't believe is unsafe, unless knowing a
client's approximate lag is problematic. The timestamp field does not need
to be based on the system's local time, and can even start with a random
integer. The SOURCE request could link to Tor Project's webpage, providing
some free advertising. ACTION also poses no safety issues, and is an
important part of the IRC experience. USERINFO and CLIENTINFO do not
provide any information that's not already available via WHOIS, though
they're not strictly necessary. DCC has many anonymity issues, and is
interfered with by Tor itself. FINGER is rarely used anymore and is not
safe to implement anyway.
Some common implementation security issues can be seen in
http://www.irchelp.org/protocol/ctcpspec.html. I have actually seen Pidgin
respond to a request while infoleaking the current conversation being
discussed in the NOTICE reply.
Please don't remove all CTCP support. Just selectively respond to
important and safe requests.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15161#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs