spacehunt.info

So we thought one way to defeat the bloody GFW is to just silently drop all RST flagged packets, which is very simple to do with Linux and iptables.

Sure enough, they are not just some random script kiddies:

220 mail.sw-linux.com ESMTP Exim 3.35 #1 Fri, 09 Jun 2006 17:40:48 +0800
HELO nanjing
250 mail.sw-linux.com Hello nanjing [218.104.86.222]
MAIL FROM: xxxx@sw-linux.com
250 <xxxx@sw-linux.com> is syntactically correct
RCPT TO: xxxx@sw-linux.com
551 User not local; please try <forward-path>
Connection closed by foreign host.

Problem is, our server never sent out that 551 error…

Capturing on eth0
  0.000000 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=107353964 TSER=0 WS=6
  0.000797 202.153.106.243 -> 218.104.86.222 TCP smtp > 33860 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=19464797 TSER=107353964 WS=7
  0.165346 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=107354120 TSER=19464797
  0.360019 202.153.106.243 -> 218.104.86.222 SMTP Response: 220 mail.sw-linux.com ESMTP Exim 3.35 #1 Fri, 09 Jun 2006 17:40:48 +0800
  0.513133 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [ACK] Seq=1 Ack=75 Win=5888 Len=0 TSV=107354476 TSER=19464887
  4.008866 218.104.86.222 -> 202.153.106.243 SMTP Command: HELO nanjing
  4.008879 202.153.106.243 -> 218.104.86.222 TCP smtp > 33860 [ACK] Seq=75 Ack=15 Win=5888 Len=0 TSV=19465799 TSER=107357979
  4.009326 202.153.106.243 -> 218.104.86.222 SMTP Response: 250 mail.sw-linux.com Hello nanjing [218.104.86.222]
  4.155527 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [ACK] Seq=15 Ack=129 Win=5888 Len=0 TSV=107358125 TSER=19465799
  9.822805 218.104.86.222 -> 202.153.106.243 SMTP Command: MAIL FROM: xxxx@sw-linux.com
  9.823256 202.153.106.243 -> 218.104.86.222 SMTP Response: 250 <xxxx@sw-linux.com> is syntactically correct
  9.960974 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [ACK] Seq=49 Ack=183 Win=5888 Len=0 TSV=107363944 TSER=19467252
 16.426632 218.104.86.222 -> 202.153.106.243 SMTP Command: RCPT TO: xxxx@sw-linux.com
 16.426928 202.153.106.243 -> 218.104.86.222 SMTP Response: 250 <xxxx@sw-linux.com> is syntactically correct
 16.448369 218.104.86.222 -> 202.153.106.243 TCP [TCP Window Update] 33860 > smtp [PSH, ACK] Seq=81 Ack=183 Win=3653056 Len=0
 16.449370 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [RST] Seq=81 Ack=183 Win=0 Len=0
 16.449994 218.104.86.222 -> 202.153.106.243 TCP [TCP Previous segment lost] 33860 > smtp [RST] Seq=1541 Ack=183 Win=0 Len=0
 16.451368 218.104.86.222 -> 202.153.106.243 TCP [TCP Previous segment lost] 33860 > smtp [RST] Seq=4461 Ack=183 Win=0 Len=0
 16.486970 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [ACK] Seq=81 Ack=230 Win=5888 Len=0 TSV=107370453 TSER=19467252
 16.582162 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [RST] Seq=81 Ack=2526652165 Win=0 Len=0
 17.303241 202.153.106.243 -> 218.104.86.222 SMTP [TCP ZeroWindowViolation] [TCP Out-Of-Order] Response: rrect
 17.452254 218.104.86.222 -> 202.153.106.243 TCP 33860 > smtp [RST] Seq=81 Ack=2526652165 Win=0 Len=0
…

Compare.

It’s as if there’s a giant transparent SMTP proxy operating in China (and also transparent IMAP4 proxies, POP3 proxies and so on.)

When you are the Party and you get to control your own network, it is trivial to play man-in-the-middle… nay, this is Party-in-the-middle.