Opened 3 years ago

Closed 3 years ago

#12402 closed defect (user disappeared)

Meek bundle occasionally makes direct contact to Tor node.

Reported by: cypherpunks Owned by: dcf
Priority: High Milestone:
Component: Obfuscation/meek Version:
Severity: Keywords:
Cc: david@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I have been testing with meek transport bundle 3.6.2.
I simply observed outbound connections with wireshark, and it was nearly always google's IP. But occasionally, it reaches out to a Tor node. In my case, it took 66 bytes from 5.135.59.74 which is a Tor node (checked with ExoneraTOR)
I think this will let the traffic observer know you are connecting to tor network.

Child Tickets

Change History (6)

comment:1 Changed 3 years ago by arma

It shouldn't do this.

Perhaps you can keep a debug-level Tor log (add "log debug file /path/to/debug-file" to your bundle's torrc file) and then look into it more when it happens?

66 bytes sure is a small number of bytes.

comment:2 Changed 3 years ago by dcf

Thank you so much for testing the bundles.

Is it possible you have another tor process on the same computer that is making these connections, rather than the tor in the bundle?

Do you have an EntryGuard line with this fingerprint in your Data/Tor/state file?

EntryGuard onion 704386F528CD7C31F8A46664A543A8A1513C949D

I found that fingerprint by searching 5.135.59.74 in Atlas. If you have such a line, it helps confirm that it is the bundle tor making the connections.

As arma says, it will be great if you can get a debug log from around the time of the connection.

comment:3 follow-up: Changed 3 years ago by cypherpunks

It was not in the EntryGuard list, there wasn't any. I don't have debug log from that time, but I was unable to reproduce it afterwards. But I didn't have system-tor or any other tor process active & running.

Late comment because I couldn't login this common account as it had its password changed for some reason.

comment:4 in reply to: ↑ 3 Changed 3 years ago by dcf

Replying to cypherpunks:

It was not in the EntryGuard list, there wasn't any. I don't have debug log from that time, but I was unable to reproduce it afterwards. But I didn't have system-tor or any other tor process active & running.

What platform are you using?

comment:5 Changed 3 years ago by dcf

  • Status changed from new to needs_information
  • Version Tor: unspecified deleted

I'm not able to reproduce this. I've had the 3.6.2-meek-1 bundle running in a Debian 7 amd64 VM, capturing all traffic as:

kvm -hda meek-leak.qcow2 -net user -net nic -net dump,file=meek-leak.pcap

I ran Bro over the pcap file to find all the addresses contacted:

bro -r ../meek-leak.pcap
cat conn.log | bro-cut id.resp_h | sort | uniq

Here are all the addresses contacted. Some are just Debian background noise.

Debian background noise:
10.0.2.15       QEMU IP
10.0.2.2        QEMU gateway
10.0.2.255      QEMU broadcast
10.0.2.3        QEMU DNS server
149.20.20.135   mirrors1.kernel.org
224.0.0.251     mDNS
255.255.255.255 broadcast
ff02::16        IPv6 multicast
ff02::1:ff12:3456       IPv6 multicast
ff02::2         IPv6 multicast
ff02::fb        IPv6 multicast 

Connections resulting from the meek bundle:
199.7.51.72     ocsp.mia1.verisign.com (OCSP server)
199.7.52.72     ocsp.lax2.verisign.com (OCSP server)
199.7.54.72     ocsp.sfo1.verisign.com (OCSP server)
206.111.16.22   206.111.16.22.ptr.us.xo.net (www.google.com)
206.111.16.27   206.111.16.27.ptr.us.xo.net (www.google.com)
206.111.16.53   206.111.16.53.ptr.us.xo.net (www.google.com)
74.125.239.110  nuq05s01-in-f14.1e100.net (www.google.com)
74.125.239.112  nuq05s01-in-f16.1e100.net (www.google.com)
74.125.239.114  nuq05s01-in-f18.1e100.net (www.google.com)
74.125.239.115  nuq05s01-in-f19.1e100.net (www.google.com)
74.125.239.132  nuq05s02-in-f4.1e100.net (www.google.com)
74.125.239.137  nuq05s02-in-f9.1e100.net (www.google.com)
74.125.239.144  nuq05s02-in-f16.1e100.net (www.google.com)
74.125.239.146  nuq05s02-in-f18.1e100.net (www.google.com)
74.125.239.147  nuq05s02-in-f19.1e100.net (www.google.com)
74.125.239.148  nuq05s02-in-f20.1e100.net (www.google.com)

And here are all the DNS queries made:

cat dns.log | bro-cut query qtype_name rcode_name | sort | uniq
15.2.0.10.in-addr.arpa  *       NOERROR
cdn.debian.net  AAAA    NOERROR
cdn.debian.net  A       NOERROR
clients1.google.com     AAAA    NOERROR
clients1.google.com     A       NOERROR
debian.local    *       NOERROR
debian._udisks-ssh._tcp.local   *       NOERROR
gtglobal-ocsp.geotrust.com      AAAA    NOERROR
gtglobal-ocsp.geotrust.com      A       NOERROR
local   SOA     NXDOMAIN
_sane-port._tcp.local   PTR     -
www.google.com  AAAA    NOERROR
www.google.com  A       NOERROR

Do you remember what was the nature of the packet received from 5.135.59.74? What port was it on? Do you remember what the data payload was?

comment:6 Changed 3 years ago by dcf

  • Resolution set to user disappeared
  • Status changed from needs_information to closed

I'm closing this ticket because I can't reproduce it and the reporter hasn't come back.

If you are able to reproduce it, it would be helpful to know:

  • What were the contents of the packet? I.e., was it a TCP SYN?
  • The debug log output.
Note: See TracTickets for help on using tickets.