Big brother is watching! GFW正在监视着你的邮件

 
 

iAmFisher 通过 Google 阅读器发送给您的内容:

 
 

于 09-1-12 通过 我blog故我在


上周和几位反垃圾邮件专家共进午餐时听他们谈到了目前仍然存在和中国墙内的邮件服务器沟通不畅的奇怪问题,其中一位已经做了不少实验和研究证明了的确是在网络上存在不明设备干扰邮件通信。想起来差不多一年多前曾经出现过GFW拦截email造成奇怪的邮件以及发信失败的问题,这些问题已经有一段时间没有听说了,我还以为GFW暂且罢手了。

拦截邮件通信是件非常可耻的行为,可以说比封锁网站更为卑鄙,为了证实以及分析问题,晚上做了几个小实验,得到的结论是令人发指的 — GFW不但正在监视着所有穿过墙的SMTP (25号端口)的通信,而且比过去发现的行为更为糟糕的是,GFW不再像过去出现的那样总是发送欺骗性SMTP错误码,而是可能直接在通讯过程中发送欺骗的RST报文使通信中断。 这种中断在实际发送email中可能会导致没有任何反馈, 也就是你以为你的邮件正常发出,但实际上邮件已经消失了,邮件的收件人永远无法收到。

更奇怪的行为是,GFW对SMTP的拦截pattern更像一个anti spam的IDS, 并不需要发送任何敏感关键词也可能导致被拦截。 据分析这可能是flg老是发送垃圾email导致GFWed的行为, 不可否认这种拦截对组织垃圾email的进入和发出是有一定作用的,然而也可能误伤无辜。

通过从美国、欧洲、日本、新加坡等多点的测试,发现行为并不仅相同,但大多表现为GFW迫不及待地代替SMTP 服务器断开连接。

测试非常容易,最简单的验证方法是拿一个sohu.com和gmail.com的邮件互发邮件测试,一个其实没有意义当含有敏感词的邮件开始还能互相发送接受,几次后这些邮件就消失了,无论是用gmail发出,或是sohu mail发出,对方都不再能收到,而且没有错误,没有退信。

更技术化些的测试是拿telnet连接到一个墙对面的smtp服务器,我随便找了个jlonline的实验,下面是通讯过程:

220 ironport1.jsmail.com.cn ESMTP
ehlo localhost
250-ironport1.jsmail.com.cn
250-8BITMIME
250 SIZE 10485760
mail from:<webmaster@jlonline.com>
250 sender <webmaster@jlonline.com> ok
rcpt to:<webmaster@jlonline.com>
250 recipient <webmaster@jlonline.com> ok

Connection to host lost.

有趣的现象是在两次250 ok后连接神秘地断开了。 当然这个测试的行为是个典型的spamer行为,到一个smtp上给冒充自己给自己发邮件。 但是为什么SMTP server说ok却突然连接断开?

当然偶抓了包来看看,可以看到最终连接断开是收到了来自server ip地址的RST报文:

image

不过来自server的正常报文的TTL值和RST报文的TTL值不同,说明这个RST报文是由网络上的神秘设备发出的:

image

上面正常的220报文的IP报头, TTL和其他整个通信中一致是 51.

image

上图是神秘的RST报文,只有这个神秘的RST报文TTL是52. 有趣的是RST报文是两个,一个TTL 51, 一个52。没有明白为何。

上述分析可能是有错误的,如果您发现了我的错误请您指出,我会迅速更正以免误导。

 

上面只是给出一个例子,实际上我看到了更综合的测试报告,虽然不能发现其行为规则,但是可以肯定存在不明设备中断SMTP的通信,而且不是每次都有错误码给出,可能导致信件的彻底丢失。

 

结论和建议

1、不要使用任何在国内的电子邮箱,通过这些邮箱发出的email会经过GFW, 可能会被审查、过滤或者消失。另外国内的电子邮件提供商可能会把你的帐户交给第三方;

2、使用国外的电子信箱的时候,web方式必须用https, 如果采用客户端那么必须在SMTP和POP3上启用TLS, 否则一样会被GFW拦截;

 
 

可从此处完成的操作: