CTCP fingerprinting

tor-messenger should beware of irc ctcp fingerprinting.

maybe it should not reply, or reply fake data for TIME and VERSION.

06:16 [ctcp(testtm)] CLIENTINFO 06:16 CTCP CLIENTINFO reply from testtm: DCC ACTION ERRMSG CLIENTINFO PING TIME VERSION 06:16 [ctcp(testtm)] PING 06:16 CTCP PING reply from testtm: 06:16 [ctcp(testtm)] TIME 06:16 CTCP TIME reply from testtm: :Thu Mar 05 2015 06:16:57 GMT+0000 (UTC) 06:16 [ctcp(testtm)] VERSION 06:17 CTCP VERSION reply from testtm: Instantbird 1.6a1pre

added component::archived/tor messenger owner::sukhbir priority::immediate resolution::wontfix severity::normal status::closed type::defect labels

Thanks for reporting this. Someone in IRC pointed this out and we were discussing on how to handle this. More tickets related to this shortly.

Trac:
Status: new to accepted
Owner: N/A to sukhbir

Trac:
Parent: N/A to #15162 (closed)

This is coming from, https://github.com/mozilla/releases-comm-central/blob/master/chat/protocols/irc/ircCTCP.jsm#L227

let version = Services.appinfo.name + " " + Services.appinfo.version;

Need to patch the application info when building.

Another related is leak is the username, which is set by default to the brand name (Instantbird).

~Instantbi@tor-irc.dnsbl.oftc.net] requested CTCP TIME from

The CTCP time leak has been fixed where we are replacing the local time with the time in UTC so that no timezone information is leaked.

For the user agent which is reflected in CTCP version (among other places) we are using Instantbird 1.5 which is the user agent of Instantbird stable.

Replying to sukhbir:

Another related is leak is the username, which is set by default to the brand name (Instantbird).

{{{ ~Instantbi@tor-irc.dnsbl.oftc.net] requested CTCP TIME from }}}

Since we are no longer trying to pretend that we are not Instantbird, we are not changing this.

And we are completely disabling the CTCP ping command.

Closing this ticket for now since we have handled all issues. Please feel free to reopen if required.

Trac:
Resolution: N/A to fixed
Status: accepted to closed

From gk's audit,

While looking over ctcp-time.patch I got reminded by the problem that Date methods may leak locale and or platform version information ("The format of the return value may vary according to the platform" (see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toUTCString). It might be worth verifiying that this is not a problem for Tor Messenger (Tor Browser had/has #5926 (moved)/#13019 (moved) and #15473 (moved) for this issue).

Trac:
Status: closed to reopened
Cc: N/A to gk
Resolution: fixed to N/A

Trac:
Parent: #15162 (closed) to #14161 (closed)

Replying to arlolra:

From gk's audit,

While looking over ctcp-time.patch I got reminded by the problem that Date methods may leak locale and or platform version information ("The format of the return value may vary according to the platform" (see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toUTCString). It might be worth verifiying that this is not a problem for Tor Messenger (Tor Browser had/has #5926 (moved)/#13019 (moved) and #15473 (moved) for this issue).

I have confirmed both with CTCP TIME and by running new Date().toUTCString() (which is what CTCP TIME calls) on all platforms and there is no difference in the result so we are not leaking anything here.

Trac:
Resolution: N/A to fixed
Status: reopened to closed

I'm not entirely convinced. Is there a TB patch we can look at?

Did you try on a different language OS as in https://trac.torproject.org/projects/tor/ticket/5926#comment:7

Are there other uses of these date function in the codebase?

Trac:
Status: closed to reopened
Resolution: fixed to N/A

https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-38.1.0esr-5.0-1&id=fdef27835764cebd9f808d00ba9402e8bda95c6f

I have confirmed on systems with non-English locale that !CTCP TIME returns the date without leaking the locale.

Additionally, we are using the Tor Browser Bundle patch from #13019 (moved) to set the JS locale to English.

Trac:
Status: reopened to closed
Resolution: N/A to fixed

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.

Trac:
Status: closed to reopened
Parent: #14161 (closed) to N/A
Resolution: fixed to N/A
Sponsor: N/A to N/A
Reviewer: N/A to N/A
Severity: N/A to Normal

Trac:
Priority: Medium to Immediate

Replying to 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.

Pull request for review: https://github.com/TheTorProject/tor-messenger-build/pull/14

We are keeping CTCP responses. The change in the above pull request is that CTCP TIME returns the time in UTC instead of the local time with the seconds timer stripped to prevent detailed time resolution.

<+sukhe> hello. yes, I think it's fine to close the tickets. thanks for doing what we should done earlier :)

sad but true: https://blog.torproject.org/sunsetting-tor-messenger

luckily there are alternatives: https://blog.torproject.org/tor-heart-onion-messaging

.. and maybe someday

• https://cwtch.im (#27364)
• https://github.com/warner/magic-wormhole/issues/8

Trac:
Status: reopened to closed
Resolution: N/A to wontfix

closed

mentioned in issue #15162 (closed)