翻墙动态

二月翻墙事件大事记： 二月翻墙工具与技术： 翻墙技术博客订阅地址及社交帐号

2016.1.19 日本站介绍 “国外信息安全专家体验防火长城” 的全文中文翻译来了。原文：http://blog.zorinaq.com/?e=81@holly_lee （Blog）翻译中文：http://weibo.com/p/1001603945665913854240体验中国的 GFW最近我第一次去了中国。作为一个信息安全专业人士，终于能够亲手摸一下中国的 GFW， 看看它是如何工作的以及翻墙的难度如何，对此我充满了好奇。简短地说，我惊讶于如下方面：它的成熟度很高。比如能够利用 TLS 的侧信道泄漏 （我有关于它能够检测到 安全 web 代理中的 ”TLS 中的 TLS“ 特性的证据）用一些简单的 Unix 安全工具就能翻墙。在中国排名最前的 3 个商业 VPN 供应商里，有 2 个 使用了太短的 RSA 密钥 （1024 位）。中国政府能够把这么短的密钥分解因数出来。（2016-02-15 更新：在接到我的报告之后，这两个供应商停止了短密钥的使用，现在它们用 2048 或者 4096 位的了）为什么要翻墙？很多到中国的西方人有非常合理的理由需要翻墙。GFW 阻止了所有的 Google 服务。这意味着没有 Gmail 来访问你的电子机票，没有 Hangouts 来跟家庭联络，没有 Maps 来寻找旅馆，没有 Drive 来存取旅行计划文档。这就是我翻墙的主要需求。在去中国前我做了一些准备。在手机上我把 Drive 应用里的文档存下来以便离线访问。在 Maps 应用里我把我要去的地方的地图预先加载好，通过放大这些地点我把附近所有的街道和景点的地图都加载到手机上了 －那时候 Google 地图还没有新的离线功能。不过最终 Maps 还是几乎没什么用：我的 GPS 位置总是与真正的地点偏离几百米远。这是因为中国的 GPS 移位问题。（Google 完全可以在它的中国地图上使用 WGS-84 坐标来解决这个问题，可它为什么至今还没做呢？）想法 1就这样我到了北京的旅馆里，试图访问 google.com。访问出错了，GFW 发送了 TCP RST 包阻止了连接。我第一个想法是建立一个 SSH Socks tunnel (ssh -D)，从我的笔记本连到美国一个数据中心的服务器上。我用了如下命令来配置 Chrome:$ google-chrome –proxy-server=socks://127.0.0.1:1080$ ssh -D 1080 my-server这种方法工作了几分钟。然后就开始出现严重的丢包，丢包率大概有 60% 到 70%。重启这个 tunnel 又能工作几分钟，然后丢包又出现了。这种丢包会影响到达服务器的所有流量，跟数据种类无关，无论是 SSH 连接还是简单的 ping 都一样。还不清楚 GFW 为什么丢弃数据包。有人说那是在不彻底阻断 VPN 的情况下，对 VPN 进行的干扰。也可能使 GFW 选择了一些可疑的数据包，将它们导向一个子系统来进行深度检测，而这个子系统过载了，没法处理全部流量。不管原因是什么，这样的掉包使得 SOCKS tunnel 变得又慢又不稳定，没法用。想法 2 我尝试了一个稍有点不同的方法：在服务器上运行一个 web 代理 (polipo)，对 127.0.0.1：$port 进行侦听，然后用 SSH 端口重定向 (ssh -L) 去访问。$ google-chrome –proxy-server=127.0.0.1:1234$ ssh -L 1234:127.0.0.1:$port my-server一样地，这种方法正常工作了几分钟，然后又出现了丢包。GFW 能够清楚地检测和干扰哪些携带了大量数据的 SSH 通信。想法 3 可以用一个在 TLS 连接之上的代理来代替 SSH。这样 GFW 应该难以检测了，因为通过 TLS 连接来访问代理的流量模式跟访问一个 https 的站点是很接近的。我们把 TLS 连接之上的 web 代理称为安全 web 代理。大多数浏览器还不支持，所以它并不普遍。我用了 stunnel 将一个代理连接包装到 TLS 里，并为我的笔记本打开了一个未加密的代理端口。当然，我需要用身份认证来保护这个配置。不过我不能用标准的代理认证方法，因为如果 GFW 连到它上面，一个 “407 需要代理认证” 就会将它暴露。我也不想用 TLS 客户端认证，因为那样很可能会表示出这可能是某种基于 TLS的 VPN。我仍然要尽可能地让我的安全 web 代理看上去像，活动起来也像一个常规的 HTTPS 端点。我用 Python 写了个短小的中继脚本，它在 $port_a 上侦听并将所有的连接转发到另外一个端点 $host_b:$port_b. 这个中继可以运行在两种模式下。在 “客户端模式” 下（在我的笔记本上）它会将一个 128 位的密钥作为发送到连接的头 16 个字节。在 “服务器模式“ 下（运行在我的服务器上）它会对这个密钥进行校验，只有校验成功才会转发连接，否则就丢弃数据，像一个失去响应的 web 服务器一样。在我的笔记本上的配置如下：配置浏览器使用 127.0.0.1:5000 上的代理中继脚本在 127.0.0.1:5000 侦听, 插入密钥，并转发到 127.0.0.1:5001stunnel 客户端在 127.0.0.1:5001 上侦听, 将连接包装进 TLS，并转发到 my-server:5002服务器端：stunnel 服务端 my-server:5002 上侦听, 解出实际连接，并转发到127.0.0.1:5003中继脚本在 127.0.0.1:5003 上侦听, 校验密钥（并移除之），然后转发到 127.0.0.1:5004Web 代理在 127.0.0.1:5004 上侦听结果如何？工作得很好！没有包丢失，没有任何问题。在通过这个代理浏览 HTTP 站点时 GFW 会在线路上看到什么呢？在我的系统上对 “curl –head http://www.google.com” 进行抓包结果显示如下 (TLS 记录的大小显示在括号里):C: TCP SYN to proxyS: TCP SYN+ACK reply from proxyC: TCP ACKC: ClientHello (86 bytes)S: ServerHello, Certificate, ServerHelloDone (67+858+9 bytes)C: ClientKeyExchange, ChangeCipherSpec, encrypted Finished (267+6+53 bytes)S: NewSessionTicket, ChangeCipherSpec, encrypted Finished (207+6+53 bytes)C: encrypted ApplicationData #1 (37+197 bytes)S: encrypted ApplicationData #2 (37+693 bytes)(旁注：ApplicationData 记录分成了两部分，第一部分 37 字节，这是为应对 BEAST 而做的 1/n – 1 记录分割）这里有一个 TCP 握手，一个 TLS 握手，一个从客户端发送的，大约 200 字节的加密 ApplicationData 记录（HTTP 请求），以及一个从服务端发送的，大约 700 字节的加密 ApplicationData 记录 （HTTP 回应）。这个 TLS 交换和流量模式类似于一个未经代理的 HTTPS 连接，因此 GFW 无法检测到它是一种翻墙技术。不幸的是，一旦我开始通过我的代理浏览 HTTPS 站点，GFW 就能检测到了并应之以大量的丢包… 它是怎么检测到的呢？想法 4通过一个安全代理浏览 HTTPS 站点会有两层 TLS：外层 TLS 连接到代理，内层连接到站点。我推断 GFW 能够猜测出加密的 ApplicationData 里隐藏了一个代理 CONNECT 请求和另一个 TLS 握手。如下为通过代理运行 “curl –head https://www.google.com” 是的抓包结果：C: TCP SYN to proxyS: TCP SYN+ACK reply from proxyC: TCP ACKC: ClientHello (86 bytes)S: ServerHello, Certificate, ServerHelloDone (67+858+9 bytes)C: ClientKeyExchange, ChangeCipherSpec, encrypted Finished (267+6+53 bytes)S: NewSessionTicket, ChangeCipherSpec, encrypted Finished (207+6+53 bytes)C: encrypted ApplicationData #1 (37+197 bytes)S: encrypted ApplicationData #2 (37+69 bytes)C: encrypted ApplicationData #3 (37+325 bytes)S: encrypted ApplicationData #4 (37+3557 bytes)C: encrypted ApplicationData #5 (37+165 bytes)S: encrypted ApplicationData #6 (37+85 bytes)C: encrypted ApplicationData #7 (37+149 bytes)S: encrypted ApplicationData #8 (37+853 bytes)对 GFW 来说，这 8 个 ApplicationData 记录看上去像 keep-alive 连接上的 4 对 HTTP 请求和回应。不过，根据 的研究所显示的，TLS 的侧信道泄漏是可以被利用的，例如用来观察包大小。试着做一下，我们能看到它们的大小符合一个 CONNECT 请求和一个 TLS 握手交换的信息大小：C: encrypted ApplicationData #1 (37+197 bytes):”CONNECT www.google.com:443 HTTP/1.1rnHost:…

各位讀者到中國的時候，為了使用 Facebook 或者電郵服務，相信會準備 VPN 來翻牆，但翻到了牆就代表安全嗎？Google 前資訊安全工程師 Marc Bevand 早前到中國旅行，當然他與我們一樣有翻牆，但他發現我們常用的 VPN 或許沒有想像中的安全。作為一個資訊安全工程師，Bevand 在網誌說能夠挑戰中國的防火長城感到好奇。此外身為行家，他當然是用「自己的方式」來翻牆，他在網誌分享了翻牆的過程。透過種種測試，他認為防火長城採用了機器學習來屏蔽可疑的連線。連線保護太弱　中國或暗中監視用戶但「自己的方式」只可以為電腦翻牆，Bevand 外出時手機仍然需要使用 VPN 。當他使用常用的翻牆工具 ExpressVPN 時發現，雖然確實能翻牆，但連線只用 RSA 1024 bit 加密。他認為 ExpressVPN 的保護太弱，中國政府有可能已解密和監聽 ExpressVPN 用戶的連線。Bevand 指中國政府很輕易便可以阻止 ExpressVPN 的服務，對於政府默許 ExpressVPN 和其他 VPN 的服務感到奇怪。他認為其中一個原因是中國政府在監視 ExpressVPN 的連線，但為了讓他們誤以為私隱受保障，政府不會干預。如果政府出手，用戶就會改用更安全的 VPN 服務，使政府無法監視。ExpressVPN 表示會在下月更新。除了 ExpressVPN ，另一個熱門 VPN 服務 Astrill 也有安全憂隱，因為第一個根認證亦只得 1024 bit。Bevand 認為資訊安全界不應再用 1024 bit RSA 加密，至少也要 2048 bit。他特別提到 ShadowSocks、Obfsproxy 和 Softether 的表現較好，但 ShadowSocks 的作者在中國當局的壓力下已把程式碼從 GitHub 下架。最後他更表示要挑戰世界各地的防火長城。翻墙技术博客订阅地址及社交帐号

墙内墙：推上 @liumiao 发现：在微信群中，在发送包含 “赵家人”的信息后，发送方会没有任何异常，好像是发送成功，但其实群内其它人并看不见这条消息。然后就有推友 @sanwolfy 回复说：QQ群早就用这一招了。以前我们班组织聚会，发送名单的时候我这边总是显示发送成功，但是别人收不到，后来才搞清楚原来是因为我们有一个叫“王丹”的。。。作死典范：Netflix 或将屏蔽用户通过 VPN 看视频 , 但又说： Netflix CEO 对进入中国市场充满信心小粉红出墙：@cuixueqin：这两天在墙内目睹一大波小粉红愤恨的叫嚣要是没有墙一定要去FB、Y2B上把台独分子撕个稀烂。那种狂暴而有愤恨的神情，让我仿佛看到一条疯狗撕扯着拴住自己的铁链，狂吠：要是没有这链子，我早替我主人把你咬死了。 来源@libearal 小粉红们的精神导师和理念传承（如果有的话）应该就是同样源于晋江的“先秦”和“凤仪”。这帮人的特点是女性、80后早期、大一统情怀、爱古风、皇汉、腐，等。对于她们这帮人，以远邪为代表的墙内右狗可能会更熟悉些，毕竟多年死对头。 来源@Dharmasong 不说推油们的日常体验，就单说小粉红越墙出击，花费巨大资源筑成的GFW带来的其实更多的是翻墙的麻烦，而不是难以克服的阻碍，GFW取得的效果以其说是因为它的技术，不如说是他利用大众的懒惰，某种程度上可以说它已经被神话了，而这种神话充斥在贵妃控制力的各个方面。 来源@mozhixu 关于小粉红：1、极权下，每个人都傻逼过；2、要转变，主要来自”被扇了一耳光“，说（启）理（蒙）基本是不可能；3、翻墙出来，会增加转变几率，值得欢迎；4、这次小粉红，是98炸馆，08圣火后的第三次大发作，当初的什锦八宝饭转变了很多嘛。5、再差，差不过如今跳广场舞这拨文革经历者； 来源翻墙技术博客订阅地址及社交帐号

来源： https://twitter.com/williamlong/status/687447659771228160【Windows Azure紧急提示: 关于自查整改“翻墙“行为的通知】根据相关法规的规定，任何公司或个人不能为非法“翻墙“ 代理网站提供托管服务，或者非法挂载任何可以连通国外网络的VPN服务。近期，监管部门已发现有几家Windows Azure客户违反相关规定，要求立即关闭其… Microsoft Azure 是微软为开发者提供的云操作系统，也是一种化软件为服务或称平台即服务（PaaS）的模式，可以为开发者提供各类操作系统支持、支持各类语言的开发环境、提供存储/缓存/及其它服务的支持。中国部分的 Microsoft Azure 由中国世纪互联 （http://www.windowsazure.cn/） 运营。翻墙技术博客订阅地址及社交帐号

最近，墙越来越高了，爬墙堪比登天。今天这款软件已经出来很久了，博主试用了很久才推荐给大家，相比比较稳定，低调试用！ Psiphon – 赛风，Android移动平台免费开源的网络加速软件，无需ROOT即可免费使用，媲美手机中继，稳定不掉线！安卓平台优秀的免费网络加速利器fqrouter、Psiphon无疑是最好的，支持赛风做得更好！赛风是赛风公司的一款新爬墙工具，利用VPN, SSH和HTTP代理软件提供未经审查的访问互联网。赛风的客户端将自动寻找新的接入点，力求最大限度的绕过网络审查。赛风旨在为您提供在线内容的开放访问。赛风不会增加暴露您的在线隐私，也不应被用作是在线安全工具。赛风3 v91 (1222) / v91.95 Pro / v91 谷歌市场版2015.12.22，普通版更新，这类软件还是保持最新！v91.95专业订阅版，新增两条线路，普通版是没有的https://psiphon.ca/PsiphonAndroid.apk 翻墙技术博客订阅地址及社交帐号

这是一封由「无名的联盟（the Nameless Coalition）」及国际各非政府组织（包括全球之声， Global Voices）撰写及联署的公开信，他们的立场代表曾因Facebook「实名制 （“authentic identity”）」而遭受伤害的人。独立媒体（香港）参与联署，我们特别对「实名制」对网络及言论自由的负面影响深表忧虑。在去年占领运动期间，有不少的Facebook用户突然被停户，并以违反「姓名规定」为由，要用户改用「真实生活中使用的名称」才可重新开户。在Facebook称这政策可「有助我们保障社群安全」的同时，本联署的促成足证其对全球不少社群，如少数性向（LGBT）社群、小数族裔社群等造成深切伤害。Facebook作为社交媒体，坐拥14亿的用户，达全球人口接近四分一。「实名制」的影响，早已超越「社交」的范畴，更是一种文化及社会的影响。在不少东南亚高压统治的国家，「实名制」更令人担忧将成政治监控的工具。我们恳切呼吁社会各关注网络及言论自由的人士，一同联署，要求Facebook改革「实名制」。联署译本如下：致 Facebook我们致函的目的，是促请 Facebook 改革其「实名制」政策。我们认为，Facebook是时候为所有用户及视 Facebook作重要发布及网上表达与交流平台的人，提供更平等的待遇及保障。我们是一群关注妇女权益、本地及小数族裔社群、LGBT性向社群、及一众认为 Facebook「实名制」政策具有文化偏见与技术性缺憾的团体与联盟。我们的立场代表：一、法定登记名称不符合其性别身份的跨性别与变性者二、为保护自己免受身体暴力、高压政权的法律威胁而匿名与修改实名者，或因对性别、性向、宗教信仰及政治活动而被骚扰者三、因攻击者滥用Facebook「假名举报」举报选项而被噤声者四、其合法名称不符合由Facebook任意订立的「实名标准」者尽管 Facebook 承诺改革这些政策，但却仍旧维持一个忽视非西方用户处境的制度，使用户身陷险地、无视他们的身份、剥夺其言论自由。滥用举报使弱势社群用户噤声根据 Facebook现行的政策，用户须以其在「现实生活（real life）」的名称开设帐户。其时，Facebook并不会要求用户提供身份证明。任何用户，只要声称其他用户违犯这项政策，便可轻易地举报。举报者并没有责任为其举报提供证据。用户可无上限、无限期地举报，这等同默许针对特定目标、无休止的举报，使政策在执行出出现不公平，并为一些希望伤害上述社群的人士，提供既危险又有效的工具。一个被滥用的举报，足以使用户永远地噤声。根据全球少数性向（LGBT）社群的Facebook用户的报告，在南亚、东南亚及中东均出现一些组织，它们（有时甚至透过Facebook发起）集体行动，以「滥用举报」功能，使性少众噤声。身份证明无法反映「现实生活的名称」面对「滥用举报」这情况（撇开举报的性质），用户如希望保留其帐户，必须提供身份证明。Facebook明确指出，个人档案名称不一定与其合法名称相符，更反覆地强调无须提供政府签发的身份证。然而，Facebook在审核「滥用举报」过程所要求提供的ID种类（无论是政府还是私人签发），不一定记有该名人士的昵称或其在「现实生活」的名称——特别是跨性别者及其他为保护自己而匿名登记者。而来自私人机构的身份证明，大多可追溯回该人士的合法身份和政府签发的身份证号码。这身份验证过程对因安全或私隐理由使用法定名称以外的名称者带来真实的危险。在某些个案里，Facebook以用户名合付政府签发身份证的政策，恢复其帐号，使用户身份曝露於曾对其施暴的前伴侣、政治性攻击，及真实世界的暴力。用户投诉无门多年来，Facebook已熟知其上诉服务的缺憾，却未有改善。一些未能提供Facebook接受的身份证明类别的个人，再没有其他方法上诉。身份证明文件必须在十天内提交予Facebook，这对不能每天上网者十分不利，他们大部份也居於非西方及发展中国家。如不能在限期内提交ID者，其帐户就会被封锁，令他们不能与其他用户沟通，也不能下载其帐户的资料数据。没有上诉渠道提供给这被踢走的用户去重新登陆帐户。ID程序：危害用户资料Facebook表示会保障用户提供的身份证明，却没有说明会如何保管其资料。监於用户大多使用没有加密的电邮提交身份证明文件，对那些参与政治活动而被监听的用户尤其不利。法律争议按照国际人权标准，任何公司均要尊重人权，有责任弥补因其生意而带来的问题。此等歧视性的排斥用户政策，也违犯了欧洲联盟相关法例和及美国民权法律的精神。如Facebook维持其政策与实行方针，置妇女、女孩、LGBT等社群於危险的境地，将打击公司声誉。如公司希望妥善对待现有及未来的用户，特别是那些身处较不发达国家的用户，他们必须尽努力配合用户的要求。我们的建议作为联盟，我们要求 Facebook落实其承诺，保障所有用户的尊严、安全及表达自由。为此，就其政策及程序，我们建议作出如下改动：一、承诺在合适的情况下，容许匿名及非法定名称。公司可透过谘询公民社会及研究当地法律，发现当使用真名或日常称谓会对个人构成危险时，弹性处理。二、要求举报者在举报时提供证据。这些证据可以书写、选项或文件的形式呈上。三、增设用户在不须提供政府签发的身份证下，可以确认身份的程序。方法可以书写、选项、文件、其他使用该匿称的平台连结。四、为用户提供提交个人身份资料的技术性指引，说明个人资料的具体使用及存放细节。提升用户使用已加密电邮提交个人身份资料的能力，使他们的私稳在传送过程有所保障。五、为被封锁帐户者提供坚实的上诉程序，让他们有渠道提出覆检、提交不同种类的证据或与Facebook员工见面，特别当个案涉及安全问题。我们期望能与Facebook一起，就其实名政策建立能发展具体及有意义的改变，以保障所有 Facebook 用户均能享有言论自由。我们要求Facebook在10月31日前作回应。我们所代表的社群深深感受到这政策对人造成的伤害，我们会一直作倡议，直至有根本性的改变出现。签署：_________________________独立媒体（香港）原文：http://goo.gl/NlxZsW英文原文：https://advox.globalvoices.org/2015/10/05/open-letter-facebook-must-change-its-broken-real-name-policy/翻墙技术博客订阅地址及社交帐号