Skip to content
Snippets Groups Projects
New look: Off

Meek bundle occasionally makes direct contact to Tor node.

    • Closed (moved) Issue created by cypherpunks @cypherpunks

    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.

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • cypherpunks added component::circumvention/meek owner::dcf priority::high resolution::user disappeared status::closed type::defect labels

      added component::circumvention/meek owner::dcf priority::high resolution::user disappeared status::closed type::defect labels

    • Roger Dingledine
      Roger Dingledine @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.

    • D
      David Fifield @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.

    • C
      cypherpunks @cypherpunks ·
      Author

      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.

    • D
      David Fifield @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?

    • D
      David Fifield @dcf ·

      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?

      Trac:
      Status: new to needs_information
      Version: Tor: unspecified to N/A

    • D
      David Fifield @dcf ·

      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.

      Trac:
      Status: needs_information to closed
      Resolution: N/A to user disappeared

    • Trac closed

      closed

    • Trac moved to tpo/anti-censorship/pluggable-transports/meek#12402 (closed)

      moved to tpo/anti-censorship/pluggable-transports/meek#12402 (closed)

    Please register or sign in to reply