twilde / 00-report.txt secret

Created November 22, 2011

Great Firewall Tor Probing Circa 09 DEC 2011
--------------------------------------------
Author: Tim Wilde, Team Cymru, Inc. <twilde@cymru.com>
Date: 06 JAN 2012
 
This analysis was performed during the week of 05 DEC 2011 - 09 DEC 2011, in
an attempt to determine the extent and type of blocking and probing being
performed by the Great Firewall of China (henceforth "GFW") against
unpublished Tor bridges located outside of China, but accessed from within
China.
 
These results are considered valid at the time of their collection (05-09 DEC
2011), and no guarantees are provided to their continuing validity beyond
that time, due to the changing nature of anti-circumvention techniques and
technologies.
 
This analysis was originated based on Tor trac ticket #4185.  A github
"gist" of the results, including this report, can be found at
https://gist.github.com/da3c7a9af01d74cd7de7
 
Pre-Analysis Conditions, Goals, and Assumptions
-----------------------------------------------
 
Prior to the initiation of this round of analysis, it had been determined
that any Tor bridge outside of China that was connected to by a client
within China would be blocked by the GFW, usually within a matter of
minutes.  Previous analysis revealed that the Tor connection initiated by
the client resulted in a series of probes from a variety of other IPs within
China (varying from connection to connection), and, within minutes of those
probes, the client's connection to the bridge would be blocked and could not
be re-initiated.  Blocking all connections to the bridge except from the
intended client was shown to allow the connection to persist successfully
for > 48 hours, thus showing a direct connection between the probing and
blocking.  This previous analysis was performed ad-hoc without dedicated
attention/resources, and the analysis described in this report was performed
as a follow-up under more stringent conditions to attempt to determine the
exact parameters of probing and blocking.
 
The primary goals of this analysis were:
 
1) Determine the extent of GFW probing of Tor connections, and more broadly,
SSL sessions in general; what triggers the probing, what time considerations
are involved, etc.
 
2) Determine how the decision to block is made.
 
3) Determine a course forward for Tor to circumvent probing and blocking.
 
It is assumed that, despite a significant series of probes originating from
a single host, the GFW does not change behavior to prevent us from learning
what they are doing.  This assumption has been tested with a smaller set of
tests from some other hosts and appears to hold true, but cannot be
conclusively proven.
 
During the previous analysis it was noted that blocking appeared to be
performed against specific destination IP:port pairings; attempting to
connect to a new port on a host after a previous connection had been blocked
was successful, but provoked new probing and blocking in the same way as the
previous port.  It is assumed that this destination IP:port pairing is still
in use in current techniques.
 
Summary of Conclusions
----------------------
 
Goal #2 was found to be unachievable at the time of analysis, as it was not
possible throughout our testing to provoke blocking.  Testing of connections
to "new" published Tor relays (exact dates for "new" not determined) showed
that even published Tor relays were connectable from within China.  Once
this was determined, focus shifted to understanding the probing and how it
could be avoided (goals #1 and #3).
 
With respect to goal #1, our testing showed that the GFW appears to perform
"garbage binary" probes of the non-China side of any connection from China
to TCP port 443 that performs an SSL negotiation.  This probe is performed
in near-real-time after the connection is established, implying
near-line-rate deep packet inspection (DPI) capabilities.  TCP/443
connections that did not actually exchange an SSL handshake, such as using
the obfsproxy obfs2 protocol, did not provoke probing.  At this time the
purpose of this probe is unknown; further details of its contents and
speculation as to its purpose can be found later in this report.
 
A second type of probing, which appears to be specifically aimed at Tor, was
also detected.  This probing appeared to occur using a client that actually
spoke SSL, and, within the SSL session, the Tor protocol, and was not
activated in real-time, but appeared to be triggered to occur at regular 15
minute past the hour intervals if its conditions were met.  Analysis showed
that the Tor SSL cipher list was at least one significant component of the
detection mechanism that initiated this probing; a client modified to remove
a sincle cipher from the list, when connecting to an unmodified unpublished
bridge in the United States, did not trigger probing.  The SSL "client
hello" packet was determined as a direct cause of the probing; when just
that data was sent to an open Tor bridge from within China using netcat, the
probing was triggered on the expected 15 minute interval.
 
A connection between a Chinese client and a US unpublished bridge node over
the obfsproxy obfs2 protocol was able to successfully persist for several
days, including numerous disconnects/reconnects, without provoking any type
of probing.
 
Recommendations
---------------
 
In the immediate term, modifying the Tor SSL client hello to present a list
of ciphers more closely (ideally identically) matching that of a common
commodity web browser would bypass the current probe trigger.  In general,
the items in Proposal 179 remain valid and a wise choice; the same eye
should be cast towards the client hello, and an attempt made to match it as
closely to commodity web browsers as possible.  With both sides of that
equation implemented, it becomes much more difficult for any authoritarian
regime to distinguish Tor traffic from standard SSL traffic, requiring
significantly more effort to locate unpublished bridge nodes and connections
to them.
 
In the longer term, the two problems that need to be solved are:
 
1) Client-server negotiation that is uniquely identifiable in any way.
 
2) The ability of an arbitrary adversary to, given a suspected Tor server
IP:port combination, connect to that IP:port combination and perform a
negotiation using the Tor protocol, or anything that can be uniquely
identified to a Tor protocol negotiation.
 
Problem #1 can be solved by a transport that either looks identical on both
sides to a standard HTTPS SSL session, or that looks like nothing
identifiable at all, like the obfs2 protocol provided by obfsproxy.
 
Problem #2 is somewhat more difficult.  Tor proposal 190 combined with the
ideas in [0] is one method that has some promise.  The "shared secret"
implementation of obfs2 in obfsproxy is another, as an adversary attempting
to initiate an obfs2 connection without the right shared secret would be
unable to get anything but noise back from the server.  That noise, however,
which the server currently emits immediately upon connection in the current
implementation, may be trivially fingerprintable, as it is not entirely
common in the wild.
 
[0] http://archives.seul.org/or/dev/Nov-2011/msg00073.html
 
Methodology
-----------
 
A single system within China was used to initiate connections to a series of
Tor bridges provisioned within the Amazon EC2 cloud computing product,
within the United States.  EC2 was utilized to allow for rapid changing of
IPs while maintaining toolsets and datasets, to eliminate possible
black/whitelisting of IPs by the GFW.  All test sessions were monitored with
full packet captures generated on the bridge nodes, and at several points in
the process Tor debug logs were captured from the bridge as well. 
Reasonable efforts were made to ensure that each test used a unique
connection tuple to prevent cross-contamination.
 
General probe observations
--------------------------
All probes came from a wide range of IP addresses within China.  A sampling
of these IPs as collected through our analysis can be found on the following
github gist:
 
    https://gist.github.com/4320b75d398f2e1f074d
 
This is by no means an exhaustive list; we have not yet undertaken to
attempt a fuller collection of probing IPs.  It is also possible that this
list contains false positives; it is simply a list of all IPs (other than
those of our test systems) geolocated to China that were observed connecting
to our unpublished bridges during the testing cycle; random scanning
activity could have snuck in, but the majority are due to active probes.
 
Each probing "session" generally consisted of multiple probes from multiple
different IPs within China.  p0f (passive OS fingerprinting) data collected
during the probes indicated that they generally originated from Linux
systems, but there was some conflicting data in the source ports used by
some probes, which appeared in ephemeral port ranges more commonly seen on
Windows systems.  This data is not conclusive in any way due to the
uncertain nature of p0f and the ability to reconfigure source port ranges at
will in modern operating systems.
 
Garbage binary probes
---------------------
 
Any connection from China to TCP/443 of a host in the US that exchanged an
SSL handshake, no matter what the certificates looked like (self-signed,
CA-signed, etc) provoked what we have termed the "garbage binary" probes
("garbage probes" for short) against the US host.  The only exception to
this seemed to be "old" hosts, which is to say, long-established hosts that
have had HTTPS services running for an extended period of time.  Connections
to those hosts did not appear to provoke any type of scanning activity.
 
The garbage probes occurred within moments of the SSL negotiation.  In some
cases, the data sent by these probes was identical, even from different
source hosts and at different times.
 
Notably, garbage probes did not occur in the case of TCP/443 connections
that spoke simple plaintext or non-SSL binary protocols, such as obfs2. 
This indicates that DPI was taking place, likely at or near line-rate, to
select which hosts should be probed.
 
Once a host was probed, subsequent connections with the same destination
outside of China did not provoke probes for approximately the next 10
minutes (measured from the final packet in a sequence of probes).  After 10
minutes, a new SSL negotiation between the hosts would trigger a new round
of probing.  The "ignored" interval remained consistent through many rounds
of testing.
 
We have not attempted to exhaustively collect and compare the data sent in
these probes, but what analysis we have performed does not provide any
insight into their purpose or intent.  It is possible that these probes are
designed to provoke a response from a different category of server that
operates on TCP/443 (and possibly other ports) and that the Chinese
government is intending to block, but that is only speculation at this time. 
It is not clear if further analysis would be worthwhile at this time given
that these probes do not, at the surface, appear to be directed specifically
at Tor.  The lack of currently active blocking resulting from any probes
also makes it difficult to evaluate the effectiveness of any changes that
might result from such analysis.
 
Full SSL/Tor probes
-------------------
 
Our testing demonstrated that the SSL client hello sent by a Tor client in
China to a US-based unpublished bridge will consistently trigger probing of
the bridge by Chinese hosts, consisting of fully-established TCP, SSL, and
Tor-protocol connections.  Analysis of debug logs from bridges in this
testing showed behavior consistent with a Tor client configured with
multiple bridge statements.  It is also possible, but impossible to
determine definitively at this time, that the probers were using custom
software either written from scratch or adapted from the Tor sources to
perform their probing.
 
Specifically, the debug logs and pcaps showed that the prober connected,
performed an SSL handshake, performed an SSL renegotiation, and then spoke
the Tor protocol.  When speaking the Tor protocol, the probers we captured
built a one-hop circuit and sent a BEGIN_DIR cell, as would be expected from
a proper Tor client.  When the bridge replies to the BEGIN_DIR cell with its
descriptor, the prober hangs up the connection.
 
This probing consistently took place within a range of +3 minutes from a 15
minute past the hour interval (HH:00, HH:15, HH:30, HH:45) after a Tor
client SSL client hello was sent from China to the US host.  Multiple
connections were made in each round of probing.  The probing occurred
consistently regardless of the TCP source and destination ports - if a Tor
SSL client hello packet was sent, on the next 15 minute interval a full
Tor-speaking probe could be expected, like clockwork.
 
Conversely, when the Tor SSL client hello was modified by removing a single
cipher from the cipher spec, full Tor connections from China to a US
unpublished bridge could be established multiple times, and for extended
durations, without provoking any probing.  Removing the less-common
ServerName SSL extension from the client hello, however, did not change the
probing behavior, indicating that the probe is likely tied specifically to
the cipher specs, not to the entire hello packet.  Unfortunately we were not
able to verify if sending a raw set of cipher specs only would trigger the
probing; this test was not performed before time on the analysis ran out.
 
The SSL cipher list probe trigger is further discussed in Tor trac ticket
#4744.
 
Server-side SSL cert impacts
----------------------------
 
Before isolating the SSL client hello as the provoker of probing, we
performed a number of tests using a simple SSL server on the US side and
openssl s_client, wget, and Firefox on the China side to attempt to locate
server SSL certificate combinations that provoked probing.  As discussed in
the garbage probing section, it appears that any SSL negotiation, even with
a fully legitimate CA-signed cert (and having used the correct hostname in
the cert to access the host, etc), will trigger the garbage probing.  On
non-standard ports, though, none of these clients provoked any type of
probing, garbage or real SSL, no matter what the server certificate looked
like.  As such it does not appear that the GFW is, today, keying on the
server certificate presented to make probing decisions.
 
Traceroute testing
------------------
 
Mike Perry posited that the prober IPs could be legitimate IPs within China
that are hijacked (partially or entirely by the GFW to perform its probes,
and suggested some traceroute testing to attempt to confirm or deny this
hypothesis.  After several false starts, we were able to successfully source
TCP traceroute packets to a prober IP using the exact same
sourceIP:sourcePort:destIP:destPort tuple that was being used for the probe,
during the probe and after the probe.  These results did not show a
different route during the probe and after the probe as Mike expected if
such hijacking were taking place, so it does not appear likely, though it
has not been conclusively disproven.
 
Additional Data
---------------
 
A number of other files are available in the github gist that contains this
report, including:
 
* testcases.txt - a list of planned test cases for the project, plotted out
  both before and during the project.  Not all cases were tested as some
  were deemed irrelevant when actual blocking could not be replicated, and
  due to other results found during testing.
 
* results.txt - a log of results obtained from working within the test cases
  described above.  Somewhat terse and difficult to interpret for anyone
  other than the author, but included for completeness. 
  Interpretation/annotation available upon request to the author.
 
* general-notes.txt - a series of general notes and a set of tentative
  conclusions formed on the final two days of testing.  These notes have
  largely been distilled, cleaned up, and expanded upon within this report.
 
* traceroute.txt - traceroute output from the traceroute testing phase
  described in a previous section.
 
* cn.log - hotpot.py output of some "garbage probes" collected early on in
  the process.
 
* client-hello.raw - the raw bytes representing a Tor client's SSL client
  hello sent via netcat to provoke full Tor/SSL probing.
 
Additionally, trusted researchers / Tor developers are welcome to contact
the author for access to the pcaps and debug logs collected during this
testing.  Due to senstive contents (IPs of probing systems, etc), we cannot
release these publicly at this time.
 
Acknowledgements
----------------
 
Thanks to Team Cymru, Inc. for providing approximately a week of the
author's time dedicated to this analysis, as well as the funding for the
Amazon EC2 bridges and facilitating the access within China.  Thanks to
George Kadianakis (asn) for his analysis assistance and help providing
direction for the testing, as well as the handy hotpot tool.  Thanks also to
too many Tor developers and other contributors in #tor-dev to count or list,
but I'll try: nickm, armadev, rransom, Sebastian, and mikeperry.  Apologies
to those I missed, it's not because you were unhelpful, I promise you!
 
Revision History
----------------
06 JAN 2012 - Initial draft published
 
07 JAN 2012 - Minor revisions and additions per feedback from George
Kadianakis.

2011-12-05 18:25:46.223838 | ''
 
2011-12-05 18:26:53.720946 | '\x80w\x01\x03\x01\x00N\x00\x00\x00 \x00\x009\x00\x008\x00\x005\x00\x00\x16\x00\x00\x13\x00\x00\n\x07\x00\xc0\x00\x003\x00\x002\x00\x00/\x03\x00\x80\x00\x00\x05\x00\x00\x04\x01\x00\x80\x00\x00\x15\x00\x00\x12\x00\x00\t\x06\x00@\x00\x00\x14\x00\x00\x11\x00\x00\x08\x00\x00\x06\x04\x00\x80\x00\x00\x03\x02\x00\x80\x00\x00\xff\x9dd\x83\xbfP\xdb/L\xd6\x88>\xfa\xbbs\x88\xbd\x0cN\xfd\x0f\x84\x8c\xad\x04x61\x99\x82\x01\x19|'
 
2011-12-05 18:26:57.973470 : 221.205.139.111:52880
2011-12-05 18:26:57.973497 | '\xaa\x14f\x82\x97\xfb\xfc\xab\xf0\xed\xafY\x9e\xd62?[\xf8JU\xf5X\xc1\xfa\x1bZZ\x9a\xe6\xd0FBV\xfb\x9fbG#\xbb\xc2?\x8b\xa2\xe1ZY\xa6h\xee0 \xe9\xea\xd1\xfb\xb9\xe5s\x0c\xb0\xc4\x12BB\xbe%\x93\xb0_\xaf\xca\x97\xd8]\x90\x89\x1b\r\xe8\x11^<\x0bt\x10\xd6\xd8\x9a\xe3\xb0w1\x14\xa0\xb8^MK\x0e\xabz\xd7\xc2\xd1\xb3\xd1Z\xcd\xdd\xc1^<}\xe7/\x8c\xbe\x86\xa6!6\x1d\xd0I=\x08&\x89\xd23\xb4\xcb\x89\xf5\x9c=\xc6\xf6\x89\xa47f_\xb3N\x8d@\x8b\x92e+\xc7\x01\xfa\x8f=\x82\xb5FTg\xf9\x9e\xf0\xee:\xac\xb4\xaf\xb4\xd7\xe6\x1b6\x99hBX\xf2\xd3\xbc\x1d\x1a\xbd\x96)y\x97\xdd\xbej\xc37\x083%B^Yp\x13\xafV\xac\xe5o\x14\'\xc6\x85z\x03!\x93\xbf6\xbb8\xcd\x18v7\xdb\xac\xbe\x8dQ\xff\xeb)\xee\xfd\xd7E\xa9\xbc\xb3<c\xf8@\xdc\xfa\xdfo9\x94+\xf0a\xc1\xe5\x18\x9c\x91\xd5*aT\x94\x89B\x11a\x069\x9c8t\xfe13Z\xaa\x91\xc9c%sS\x064\xb7\x1dPHq\xf8\xa9\xc4\x8c\xb1\x85\x1c\x12\x8bT.\xc2G,ry\x86\x1d\n\xce\xfe\xad\xc0\xd0\xb2s\x87N\xc2N\xbe:\xf6\x02E\xa8\x87`9\x91\xb3fS\xf9\x12E\xf1\x17az\xe4\xde($\xaeY\x965\xa7\xd8\x82\xe4\x12\xf8\xe6\xd6 \xec6X}i>O\xe1O\x93\xd3\xe4s\xcc\xc8Q\xf3\xeb\xfe\xcc\x01\xb2s\xd8\xb4W\xea\xac\xbc@K\xa8\xf4"\xa4]_\xf3\xbe-\x06\x11\x11y\xdcXIP\xc2\xc7\x1c\xc3y\x0e\x1b\xacd\x05X\xa0\xc3\xa2H\xb8Dl\x94\xa2\xdeRO\xe3\xe1\xde\xdb\xbe\xb6%\x8d\xf7k'
 
2011-12-05 18:26:58.839414 : 218.10.51.83:1629
2011-12-05 18:26:58.839469 | '\xd7s\x10\x05\x95\x86\xe6\x89ok\x07\xd2\x95\xab}\x16\x10\xc4\xc8F\xac|ax\x86d\xc6\x03\x19_=\xd1\x13W\x14\x8dG\x0e;Y.\'\xd2\x90\xa3\xab X\xb1w\x97\xe4e\xd8A=\xc7\xd0\xe4S\xc46\xcb\x86\xea9\x9bIz\xe0\xa8\xe7\xb7\x1b\x8c\xa8H\x1aK\xfdl\t\xdf\xa0\xb4\xd3\xcd\xe8r~\xd5\\u\xfa\xdb\xab\xad\xf5s\'U\x9a\x0e\x0c4\x993|3\xfc\xf8\x1e\x85\xd8\xbd9\xab\n!\x9d\x87vx\xfbp\xd2&\x9c\xc7\x18\xc2\x1c\xb1O\xa6eg\xd8`\x99UX\xb6\xd90s\x12[|\xb2\xf7\x83(\xee~\x17\xc0$\xb2\x87;\xf3"lB\xc7\xd0\xa8\x1f\xaf\xc1s\x07wL\xb6j\xdd\x11e\x8f\x87\xe76u\xe5\xcb5\t};C\xef\\\xae1\xa2\xfdX\xc0\xac\x19\xb33\x90\xfe\xe8y[\xf8]\xe9\xfeE\x9es\xa9i\'\xb1easT<\xa1\x84]\x9e\xdc\x9c\xcatO\xfc\x04\xcdd\xfb(\xdbY\x91\xd9\x1d/L\xc5\x98\xf1\xf5|Rh\xd0\r\t\xd3i\'/\x84p\xa3\xd3l&\xa0\xcf"G*\xf9\xd7\x03\x16\x07\xcdZ\x1e'
 
2011-12-05 18:26:59.704311 : 112.94.175.239:35960
2011-12-05 18:26:59.704387 | '\xcb\x11E.\xf7I\x91Y\x92{\x00\x0f\xd0&\xc3\x1c\xe1Tq\xe3C\xf9\xd9\xfd\xeb}\x8c\xd2\xfc\xa5\xf9K\x9f\x8c*\x86\xdb\x1f\xe3\x19v\xd951\xb6Ep\xa4\xde\x1cJ\xd1S\x95\',\xa9\xdc\xba\x03y\xc0\xfc\xe7\x9b\x12\x1f\xee\x18k\xa5\xdb75H\xe8\x84\x97+2\xbb\xd1*\xaa\xef\xb1\xb3\t7\xaf4{\xa2\xbf\x05\xac>#\x9aU\x8e\xbe0D\xf3\xf7\xab\xf6\x0e\xd5\xa7H\xa6Pq\x95\x01$\x1d\xb6\xd3P1\xf4\x8e5 \xcbX: ew\xcf\xa8jFS\xdf\xd2\xa7\x86\x1bM\xd5\x0baU/}\x0c\x81L\xbb\xf4\xdap\x14\xa5G\xccE\xabD\x14\xd2-\xd8\xa4\r\xaaK\x12\xc4\x17gOw;}s\xc5\xfd\xbe\x81\xf1\x18p\x84=\xb6Q\x81\xe0\x14\x142@\xeb\xd5\xcb\x95\x9f]\xd95\xc3(+}$\x9dC\xa0\xdaC\x11r\xb2\x94\xae\xe7d/Gw\xc1x7\xac\xcc\x02\xc0k^\x99\x1f\xa0@I\x1ece`\x03?"\x130S\'\xdd:\x8a\x8b\x80\x81Lw\xb7wC88-\x96\xd0K6\x11\x93\xd2\xf2w\xb1\xf55\xd2\x87e%\xadB\xdd8M\xdc8\x98S\xee\x10\x95&G\xc1;\x96\x8bq&\x9d\xc2\x19\x14t\x8dIF\x14\xad\xea\xc1nGx\xba$\xaf\xd2v\x1d\xe1\x8bB\xa7L}\xbcWm\xe2\xf3\xaez\x87"\x86\xcf\xe7\x99\xfbQ\xd9\xe8\x97\xd0\xa3\xba\x7fu\xb0\x9b\xd5;]\xfb\x06Y\xb7\\E\x19\xcf\xf2\x12V\x94\x97\xa4{\xb0\x9f\xcb\t\x87b\xd9\xa9\x9c\xd7\x9dL'
 
2011-12-05 18:27:00.785398 : 113.58.246.59:19316
2011-12-05 18:27:00.785443 | '\xcb\x11E.\xf7I\x91Y\x92{\x00\x0f\xd0&\xc3\x1c\xe1Tq\xe3C\xf9\xd9\xfd\xeb}\x8c\xd2\xfc\xa5\xf9K\x9f\x8c*\x86\xdb\x1f\xe3\x19v\xd951\xb6Ep\xa4\xde\x1cJ\xd1S\x95\',\xa9\xdc\xba\x03y\xc0\xfc\xe7\x9b\x12\x1f\xee\x18k\xa5\xdb75H\xe8\x84\x97+2\xbb\xd1*\xaa\xef\xb1\xb3\t7\xaf4{\xa2\xbf\x05\xac>#\x9aU\x8e\xbe0D\xf3\xf7\xab\xf6\x0e\xd5\xa7H\xa6Pq\x95\x01$\x1d\xb6\xd3P1\xf4\x8e5 \xcbX: ew\xcf\xa8jFS\xdf\xd2\xa7\x86\x1bM\xd5\x0baU/}\x0c\x81L\xbb\xf4\xdap\x14\xa5G\xccE\xabD\x14\xd2-\xd8\xa4\r\xaaK\x12\xc4\x17gOw;}s\xc5\xfd\xbe\x81\xf1\x18p\x84=\xb6Q\x81\xe0\x14\x142@\xeb\xd5\xcb\x95\x9f]\xd95\xc3(+}$\x9dC\xa0\xdaC\x11r\xb2\x94\xae\xe7d/Gw\xc1x7\xac\xcc\x02\xc0k^\x99\x1f\xa0@I\x1ece`\x03?"\x130S\'\xdd:\x8a\x8b\x80\x81Lw\xb7wC88-\x96\xd0K6\x11\x93\xd2\xf2w\xb1\xf55\xd2\x87e%\xadB\xdd8M\xdc8\x98S\xee\x10\x95&G\xc1;\x96\x8bq&\x9d\xc2\x19\x14t\x8dIF\x14\xad\xea\xc1nGx\xba$\xaf\xd2v\x1d\xe1\x8bB\xa7L}\xbcWm\xe2\xf3\xaez\x87"\x86\xcf\xe7\x99\xfbQ\xd9\xe8\x97\xd0\xa3\xba\x7fu\xb0\x9b\xd5;]\xfb\x06Y\xb7\\E\x19\xcf\xf2\x12V\x94\x97\xa4{\xb0\x9f\xcb\t\x87b\xd9\xa9\x9c\xd7\x9dL'
 
2011-12-05 18:30:43.346920 | '\x80w\x01\x03\x01\x00N\x00\x00\x00 \x00\x009\x00\x008\x00\x005\x00\x00\x16\x00\x00\x13\x00\x00\n\x07\x00\xc0\x00\x003\x00\x002\x00\x00/\x03\x00\x80\x00\x00\x05\x00\x00\x04\x01\x00\x80\x00\x00\x15\x00\x00\x12\x00\x00\t\x06\x00@\x00\x00\x14\x00\x00\x11\x00\x00\x08\x00\x00\x06\x04\x00\x80\x00\x00\x03\x02\x00\x80\x00\x00\xff\xcd]\x06\xb5S\xdb\x87\x8e\x06\x1a\x14\xfd\xf0\xd5;\x81\xf6(\xeaB\xb0)(&\x9d\xaf\xcc\xc0g2\x1a\xf4'
2011-12-05 18:30:46.450253 < 'foo\n'
2011-12-05 18:30:46.450253 > '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
2011-12-05 18:30:56.230631 < 'bar\n'
2011-12-05 18:30:56.230631 > '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
2011-12-05 18:30:57.130697 < 'baz\n'
2011-12-05 18:30:57.130697 > '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

Tentative Conclusions 08 DEC 2011
---------------------------------
Based on the data so far, it appears that all TCP/443 connections out of 
China to previously-uncategorized hosts are subject to DPI, and, if an SSL
handshake of any type is detected, subject to active probing.  TCP/443
connections that do not speak obvious SSL (ie obfs2 protocol) do not appear
to be probed.  TCP/443 connections to "old" hosts (definition of "old" is
very much unknown at this time) do not appear to cause probing.
 
SSL connections to other TCP ports, including "SSL-expected" ports like
TCP/993 and TCP/995, do not appear to initiate probing, no matter how
provacative the certificates in use.  This is a change from previous
behavior; during investigation of #4185 in October 2011, Tor and other SSL
connections on non-TCP/443 ports were definitely probed (and blocked).  It
appears that the GFW's SSL probing has been significantly changed since that
time.  Further investigation is still ongoing.
 
Update 1640 UTC: A non-obfs2 Tor connection to a random high port
(TCP/18457) on a virgin non-published bridge IP resulted in an SSL-connected
scan that appeared to act as a Tor client (not yet confirmed from debug
logs) several minutes after the initial connection was established (and
reconnected several times).  More than 10 minutes after the probing, the
bridge IP:PORT had not yet been blocked.
 
Update 2100 UTC: The full SSL-speaking (and tor-speaking) probes appear to
happen consistently at roughly 15 minute-past-the-hour intervals (:00, :15,
:30, :45).  This is consistent to a range of +3 minutes through all of the
samples we've collected so far (with only one outlier in the +3 minute
range, all others within 1 minute of the 15 minute mark).
 
Thus far we have been unable to provoke this type of probing using anything
other than a full Tor connection.  SSL connections to non-Tor servers, even
those using Tor-like SSL certificates, have not been able to trigger it.
 
The Tor connection does not need to be persistent to trigger the probing; a
short connection just long enough to build a circuit, made only 2-3 minutes
before a "scheduled" scan time, was enough to provoke a scan at the next
interval.  A similar duration circuit right after a previous "scheduled"
scan time also provoked a scan at the next interval.
 
An openssl s_client connection to an actual Tor server did NOT provoke a
scan of this nature.
 
TCP traceroute to an SSL/Tor-speaking prober during and after a probe does
not yield any change.  See traceroute.txt for a sample.  Still pending:
using the same sourceport with a handy iptables trick thanks to mikeperry.
 
09 DEC 2011
-----------
A connection to Tor 0.2.3.8 from a Tor 0.2.3.8 client with the ServerName
SSL extension removed still provoked probing.
 
A connection to Tor 0.2.3.8 from a Tor 0.2.3.8 client with a reduced SSL
cipher list did NOT provoke probing.  Further testing is in progress.
 
The iptables trick did not work for traceroute with an identical
sourceip:sourceport:destip:destport tuple; my suspicion is that conntrack
gets in the way of the rewriting.  Additional data added to traceroute.txt
(see data for 60.13.132.232).
 
Subsequent tweaking of the iptables trick returned the traceroute data for
113.58.244.209, which showed no difference between "during probe" and "after
probe" in the short term.
 
Observations
------------
* Probing will re-occur with new connection attempt to a previously probed
  (but not blocked) system if repeated after more than 10 minutes.  New 
  connections less than 10 minutes after a previous probe do not generate
  new probes, even if the SSL certs exchanged are changed.
  * The 10 minute timer appears to start from the time of the final probe in
    a sequence, not the first probe.
* Probing occurs within moments of an SSL exchange that contains a
  "probable" cert / cert chain within the constraints of the time limit
  notes above.
* Several probes are initiated in each instance of probing, from multiple
  hosts.
 
Plans
-----
* Use cronned */5 TCP ping to each port from inside CN to verify
  reachability

2) obfs2 transport (https://gitweb.torproject.org/obfsproxy.git)
----------------------------------------------------------------
Initial instance of obfs2 on TCP/443 generated one set of probes that
did not conform to other probe methodologies.  No repeats occurred with
over two hours of operation and disconnects/reconnects.
 
Subsequent use of obfs2 on a new TCP port did not provoke any probing
with over an hour of operation and disconnects/reconnects as well as
(failed, but intended to fail) openssl s_client and wget connection
attempts.
 
A longer duration obfs2 test back on TCP/443 on a fresh clean IP did not
reveal any probing in over 24 hours of execution.
 
3) Tor-like-SSL (control)
-------------------------
TCP/443:
* hotpot.py: triggers probing, does not cause blockage.
* server.pl: triggers probing, does not cause blockage.
* unpublished tor 0.2.3.8 bridge: openssl s_client triggers probing, no block
* unpublished tor 0.2.3.8 bridge: tor 0.2.3.4-alpha client triggers
  probing, no block
* unpublished tor 0.2.3.5 bridge: tor 0.2.3.4-alpha client triggers
  probing, no block
* unpublished tor 0.2.3.4 bridge: tor 0.2.3.4-alpha client triggers
  probing, no block
* apache-wget: triggers probing, does not cause blockage.
 
TCP/14392:
* server.pl: no probing
 
TCP/18457:
* unpublished tor 0.2.3.8 bridge: openssl s_client does not trigger probing
* unpublished tor 0.2.3.8 bridge: tor 0.2.3.4-alpha client triggers real SSL
  probing, with several minute delay (probing occurred at ~30 minutes past
  the hour)
* The above two tests were performed in close proximity and can't be nailed
  down; further testing pending.  Bridge IP for this test was 50.17.159.162.
 
TCP/16415
* unpublished tor 0.2.3.8 bridge: tor 0.2.3.4-alpha client triggers real SSL
  probing 10 minutes after Tor connection established (probing occurred at
  ~45 minutes past the hour)
  * results replicated again, this time with scanning at :00 past the hour.
 
4) Self-signed cert
-------------------
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            9f:46:4c:ab:e1:db:41:bb
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=Minnesota, L=Duluth, O=Joe Bloggs, LTD, CN=iscream.4dq.com/emailAddress=root@null.com
        Validity
            Not Before: Dec  7 16:22:02 2011 GMT
            Not After : Dec  6 16:22:02 2012 GMT
        Subject: C=US, ST=Minnesota, L=Duluth, O=Joe Bloggs, LTD, CN=iscream.4dq.com/emailAddress=root@null.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
 
* apache-wget TCP/443: triggers probing
 
5) Real CA-issued cert
----------------------
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0f:5b:4e:f2:f3:68:af:a5:83:a3:37:e1:15:7c:c8:b2
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=PositiveSSL CA
        Validity
            Not Before: Dec  7 00:00:00 2011 GMT
            Not After : Dec  6 23:59:59 2012 GMT
        Subject: OU=Domain Control Validated, OU=PositiveSSL, CN=www.joebloggsltd.net
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
 
* apache-wget TCP/443: triggers probing
* apache-firefox TCP/443: triggers probing
 
* apache-firefox to www.team-cymru.org: does not appear to trigger probing
 
* apache-wget TCP/14952: no probing
* apache-firefox TCP/14952: no probing
 
7) Firewall everybody but the intended user of the bridge.
----------------------------------------------------------
Clients in China provided access to a bridge that permitted access only to a
set of explicitly whitelisted IPs were able to access the bridge for >48
hours without blockage.
 
8) Other protocols for reference (ssh, ftp, smtp, smtps)
--------------------------------------------------------
* POP3S CA-signed cert: no probing
* POP3S self-signed cert: no probing
* POP3S tor-like cert: no probing
 
9) TCP connection/scan with no SSL handshake
--------------------------------------------
hping -S -p 443 <test IP> and telnet <test IP> 443 both failed to generate
scanning to a server which did generate scanning when connected via openssl
s_client.
 
13) Relay with debug verbosity after SSL-based probing duplicated
-----------------------------------------------------------------
Upon analysis of debug logs from a 0.2.3.8-alpha bridge, SSL-based probes
from CN appear to be speaking the Tor protocol, similar to the behavior
of a client with multiple bridges configured that is not actively using
our bridge.

1) Handshakes using OpenSSL and libnss
2) obfs2 transport (https://gitweb.torproject.org/obfsproxy.git)
3) Tor-like-SSL (control)
4) Self-signed cert
5) Real CA-issued cert
6) Vary responses of bridge to probing as well as initial handshake (independently if possible)
7) Firewall everybody but the intended user of the bridge.
8) Other protocols for reference (ssh, ftp, smtp, smtps)
9) TCP connection/scan with no SSL handshake
10) Connection into China-hosted bridge from outside of China, which side (if any) gets probed?
11) Handshakes using real Apache on the server side
12) Tor 0.2.1.x stable
13) Relay with debug verbosity after SSL-based probing duplicated
14) Determine how many negative probes it takes for the GFW to say "this is
    not worth probing anymore" (may prove difficult)

Sample traceroute to a prober during a probe:
 
 traceroute -T -O ack --sport=993 -n -p 6885 113.58.244.51
traceroute to 113.58.244.51 (113.58.244.51), 30 hops max, 40 byte packets
 1  10.208.200.3  0.360 ms  0.314 ms  0.237 ms
 2  10.1.18.13  0.447 ms  0.382 ms  0.389 ms
 3  10.1.19.14  0.460 ms  0.369 ms  0.344 ms
 4  216.182.232.50  0.686 ms  0.674 ms  0.439 ms
 5  72.21.222.148  0.830 ms  0.931 ms  0.742 ms
 6  72.21.220.52  1.152 ms  1.121 ms  1.191 ms
 7  168.143.232.49  1.050 ms  0.921 ms  0.996 ms
 8  129.250.3.118  2.783 ms  2.280 ms  2.733 ms
 9  192.205.37.53  3.535 ms  3.189 ms  3.045 ms
10  12.122.134.134  76.622 ms  75.564 ms  76.007 ms
11  12.122.18.21  73.662 ms  71.409 ms  71.971 ms
12  12.122.31.85  71.701 ms  72.252 ms  71.765 ms
13  12.122.30.25  77.486 ms  75.511 ms  75.763 ms
14  12.122.30.30  70.226 ms  72.362 ms  71.562 ms
15  12.123.30.249  70.481 ms  70.040 ms  70.323 ms
16  12.122.129.145  73.380 ms  73.415 ms  73.626 ms
17  12.116.103.6  289.428 ms  289.163 ms  289.259 ms
18  219.158.4.177  280.133 ms  280.081 ms  279.180 ms
19  219.158.15.10  285.558 ms  277.110 ms  277.112 ms
20  219.158.23.242  295.061 ms  295.484 ms  295.082 ms
21  221.11.155.250  295.448 ms  295.591 ms  295.428 ms
22  221.11.160.14  298.747 ms  301.180 ms  301.139 ms
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  *^C
 
After the probe:
 
 traceroute -T -O ack --sport=993 -n -p 6885 113.58.244.51
traceroute to 113.58.244.51 (113.58.244.51), 30 hops max, 40 byte packets
 1  10.208.200.3  0.321 ms  0.230 ms  0.268 ms
 2  10.1.18.13  17.777 ms  1.088 ms  0.384 ms
 3  10.1.19.14  0.644 ms  0.541 ms  0.613 ms
 4  216.182.232.50  0.743 ms  0.685 ms  0.745 ms
 5  72.21.222.148  0.953 ms  0.975 ms  0.694 ms
 6  72.21.220.52  1.193 ms  0.999 ms  1.186 ms
 7  168.143.232.49  0.844 ms  1.032 ms  0.947 ms
 8  129.250.3.118  2.337 ms  2.236 ms  2.241 ms
 9  192.205.37.53  3.386 ms  3.232 ms  3.287 ms
10  12.122.134.134  75.566 ms  75.584 ms  75.913 ms
11  12.122.18.21  72.999 ms  71.614 ms  72.121 ms
12  12.122.31.85  72.872 ms  72.201 ms  72.168 ms
13  12.122.30.25  74.797 ms  76.056 ms  75.605 ms
14  12.122.30.30  73.746 ms  72.219 ms  71.538 ms
15  12.123.30.249  70.312 ms  70.102 ms  70.144 ms
16  12.122.129.145  71.867 ms  72.608 ms  72.667 ms
17  12.116.103.6  289.208 ms  289.009 ms  289.292 ms
18  219.158.4.177  280.327 ms  280.069 ms  280.181 ms
19  219.158.15.10  277.672 ms  277.070 ms  277.369 ms
20  219.158.23.242  295.198 ms  295.630 ms  295.114 ms
21  221.11.155.250  296.065 ms  295.571 ms  295.917 ms
22  221.11.160.14  301.651 ms  301.019 ms  301.074 ms
23  * 221.11.160.14  299.997 ms  301.065 ms
24  * * *
25  * * *^C
 
Sample using mikeperry's iptables hack to use the same exact TCP tuple as
the live connection, while it was live it failed; pcaps showed that the
packets weren't going out at all, and appeared to be eaten at the iptables
layer.
 
 traceroute -T -O ack --sport=1234 -n -p 15713 60.13.132.232
traceroute to 60.13.132.232 (60.13.132.232), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  *^C
 
But the same ports to a different IP were okay:
 
 traceroute -T -O ack --sport=1234 -n -p 15713 1.2.3.4
traceroute to 1.2.3.4 (1.2.3.4), 30 hops max, 40 byte packets
 1  10.208.200.3  0.432 ms  0.355 ms  1.001 ms
 2  10.1.16.13  0.593 ms  0.576 ms  0.339 ms
 3  10.1.17.14  0.349 ms  0.425 ms  0.436 ms
 4  216.182.224.82  0.645 ms  0.479 ms  0.436 ms
 5  72.21.222.148  0.691 ms  0.680 ms  0.733 ms
 6  72.21.220.36  40.609 ms  1.297 ms  1.244 ms
 7  168.143.232.73  1.207 ms !N  1.361 ms !N  1.499 ms !N
 
And after the prober closed its connection:
 
 traceroute -T -O ack --sport=1234 -n -p 15713 60.13.132.232
traceroute to 60.13.132.232 (60.13.132.232), 30 hops max, 40 byte packets
 1  10.208.200.3  0.328 ms  0.268 ms  0.284 ms
 2  10.1.14.13  0.412 ms  0.520 ms  0.283 ms
 3  10.1.15.14  0.393 ms  0.424 ms  0.441 ms
 4  216.182.224.78  0.497 ms  0.429 ms  0.501 ms
 5  72.21.222.148  0.806 ms  0.728 ms  0.688 ms
 6  72.21.220.68  0.870 ms  0.972 ms  0.931 ms
 7  168.143.191.17  1.439 ms  1.325 ms  1.378 ms
 8  192.205.37.53  3.388 ms  3.271 ms  3.050 ms
 9  12.122.134.134  73.478 ms  71.643 ms  71.718 ms
10  12.122.18.21  76.272 ms  75.908 ms  78.250 ms
11  12.122.31.85  74.103 ms  71.976 ms  82.942 ms
12  12.122.30.25  75.551 ms  74.995 ms  76.269 ms
13  12.122.30.30  73.357 ms  75.962 ms  75.576 ms
14  12.123.30.249  73.233 ms  73.750 ms  73.583 ms
15  12.122.129.49  74.569 ms  74.515 ms  73.608 ms
16  12.118.130.86  238.895 ms  282.266 ms  252.014 ms
17  219.158.96.221  240.930 ms  240.885 ms  240.886 ms
18  219.158.96.225  242.314 ms  242.288 ms  242.288 ms
19  219.158.23.94  311.817 ms  311.760 ms  311.904 ms
20  221.7.2.250  314.890 ms  314.793 ms  314.791 ms
21  221.7.3.26  313.309 ms  313.450 ms  313.255 ms
22  * * *
23  * * *^C
 
Another prober, this time actually during the probing thanks to more
iptables and routing hackery:
 
 traceroute -T -O ack --sport=1234 -n -p 18339 113.58.244.209
traceroute to 113.58.244.209 (113.58.244.209), 30 hops max, 40 byte packets
 1  10.208.200.3  22.941 ms  4.654 ms  0.896 ms
 2  10.1.14.13  0.308 ms  0.294 ms  0.335 ms
 3  10.1.15.14  0.400 ms  0.446 ms  0.353 ms
 4  216.182.232.50  0.614 ms  0.492 ms  0.457 ms
 5  72.21.222.148  0.657 ms  0.689 ms  0.749 ms
 6  72.21.220.52  1.107 ms  1.243 ms  1.206 ms
 7  168.143.232.49  1.208 ms  1.221 ms  1.207 ms
 8  129.250.3.118  2.107 ms  2.286 ms  2.263 ms
 9  192.205.37.53  11.880 ms  3.407 ms  3.336 ms
10  12.122.134.134  72.544 ms  71.551 ms  71.749 ms
11  12.122.18.21  72.905 ms  75.897 ms  75.792 ms
12  12.122.31.85  77.837 ms  75.563 ms  76.777 ms
13  12.122.30.25  76.276 ms  75.540 ms  76.331 ms
14  12.122.30.30  73.454 ms  74.699 ms  71.855 ms
15  12.123.30.249  74.593 ms  74.357 ms  74.842 ms
16  12.122.129.145  73.903 ms  69.713 ms  72.209 ms
17  12.116.103.10  279.680 ms  279.639 ms  279.349 ms
18  219.158.3.161  266.821 ms  269.409 ms  267.077 ms
19  219.158.96.54  256.382 ms  254.179 ms  254.349 ms
20  219.158.14.106  306.252 ms  306.526 ms  306.267 ms
21  221.11.155.250  305.514 ms  305.254 ms  305.474 ms
22  221.11.160.14  308.502 ms  310.979 ms  311.144 ms
23  * * *
24  * * *
25  * * *
26  *^C
 
And the same prober, > 5 minutes after the probe:
 
& traceroute -T -O ack --sport=1234 -n -p 18339 113.58.244.209
traceroute to 113.58.244.209 (113.58.244.209), 30 hops max, 40 byte packets
 1  10.208.200.3  0.439 ms  0.278 ms  0.236 ms
 2  10.1.14.13  5.294 ms  1.225 ms  0.739 ms
 3  10.1.15.14  0.385 ms  0.430 ms  0.442 ms
 4  216.182.232.50  7.351 ms  0.657 ms  0.501 ms
 5  72.21.222.148  0.798 ms  0.719 ms  0.757 ms
 6  72.21.220.52  1.056 ms  1.101 ms  1.108 ms
 7  168.143.232.49  1.062 ms  1.192 ms  1.017 ms
 8  129.250.3.118  2.472 ms  2.231 ms  2.240 ms
 9  192.205.37.53  3.337 ms  3.206 ms  3.288 ms
10  12.122.134.134  73.007 ms  72.235 ms  71.503 ms
11  12.122.18.21  75.957 ms  76.638 ms  75.013 ms
12  12.122.31.85  74.581 ms  76.336 ms  76.061 ms
13  12.122.30.25  74.598 ms  76.213 ms  75.506 ms
14  12.122.30.30  72.519 ms  72.265 ms  71.669 ms
15  12.123.30.249  74.450 ms  74.448 ms  74.605 ms
16  12.122.129.145  69.584 ms  69.976 ms  69.622 ms
17  12.116.103.10  279.630 ms  279.473 ms  279.406 ms
18  219.158.3.161  266.466 ms  266.928 ms  267.200 ms
19  219.158.96.54  254.338 ms  254.340 ms  254.042 ms
20  219.158.14.106  306.293 ms  306.199 ms  306.074 ms
21  221.11.155.250  305.337 ms  305.372 ms  305.138 ms
22  221.11.160.14  305.191 ms  311.037 ms  312.963 ms
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *