A few ideas for your Proxy 2.0

有鉴于Proxy将成为贫苦大众(特指“没能力购买网络服务”的网民)今后数年的必备用品,Proxy 1.0的原始框架已无法承载这种压力。最近不少Proxy 2.0的设计蓝图浮出水面,本人亦有一些考量,这里简单小结一下。

Security or Obscurity ?

Build your dam for reasonable tsunami, not 2012. Lay your tarmac for reasonable vehicles, not Transformers.

2.0的其中一种思维是增强Proxy Security,强制HTTPS协议是首选的方式。我觉得还可以换个角度看,很多时候用户需要的并不是安全性,或者说使用Proxy的网民大多数并不清楚如何增强安全性。这时我们需要的是增加Obscurity,当然不是指降低用户界面的易用性,而是增加生成HTML代码的委婉性

搞过计算机安全的人都知道Security through Obscurity是没戏的,那为什么放弃Security选择Obscurity呢?理由简单,基于使用Proxy的初衷。若我们希望完全防止MITM,那Security是必须的;但“窃听者是全能的”的假设是否适合一个Public Proxy?我认为值得商榷。如今用户期待的是“能正常浏览网页”,而不是“安全匿名的浏览网页”。再者,安全匿名不仅必须加密通信,还需要用户完全信任服务器运营者才行,验证后者比技术上保证前者更加困难。

降低安全假设的好处在于它能大幅度延展Proxy的设计选择。说得很玄乎,实际操作很简单。举个例:关键词破坏是国内网站常用的手段,为什么我们不能挪为己用?当然,实际运行时我们可以稍微修改一下“破坏”的方式。

正太什么的最讨厌了,萝莉万岁!

以上句子在客户端上看没有任何问题,但对于机器来说,它是——

<p>正太<span style=”display:none;”>什么的最讨厌了,萝莉</span>万岁!</p>

如此一来,正太控的内容被正常浏览了,而机器还以为我们是不懂网页标准的萝莉控。这种设计有数条好处——

  • 这种模式可以有无数种变形,大幅度增加了Keyword Matching的难度。
  • 既然有机器喜欢读我们的HTML,那就让他们去读好了,避免额外加密
  • 它比客户端解RSA靠谱。运行速度和浏览体验都更胜一筹。

牺牲复制粘贴(插入文字也会被复制)换来的是运行效率与更新速度。Proxy服务器用display:none和eval等方式处理文字与链接(Pattern Matching)比加密整个页面便宜得多。更可以在站外维护一个Keyword List,允许用户提交反馈,定时更新,照顾最新的指示。

A Hell for Computation Overlord.

智能系统最喜欢的东西:可预测的环境。不要给它们任何机会,尽可能破坏所有既定的网络规定。假如对方熟悉Base64与ROT13,我们就把URL换成用户可自定义的同样快速的Substitution Cipher,把随机的Client Key藏在Cookie里。若Client Key对不上,相同的请求服务器只会返回错误。我们甚至可以进一步混合时间限制,以免Client Key被重复利用。

破解Substitution Cipher需要26!个单位时间,已经大幅度超出智能系统可承受的范围。若尝试截取Client Key,则陷入Uncertainty的游击战。Obscurity再次立功。

Where is my invisible coat ?

等你成功穿越Overlord,它的手下就要来找你了,于是谈到Proxy 2.0真正的瓶颈所在——假如IP或域名下水了,Proxy的命运也到此为止。在IPv6和TLD大开放的时代(又称“网络廉价化”的时代)还没到来之前,这些东西都是非常珍贵的资源。

为此,所谓Proxy Chain需要与时代并进,履行Behavioral Separation,设置一个Reverse Proxy在Web前端,将后端服务器处理过的内容传送至客户端。不少简单的Proxy都可以改造为Reverse Proxy,放置在可爱的免费空间上,即便Reverse Proxy不幸意外,主服务器还是安全的。

与此同时,一个只处理数据的服务器也比一个拥有华丽前端的服务器隐蔽,降低被当成炮灰的风险。

回应小标题的提问——你不用的时候往invisible coat上贴个标签不就好了。别让问题卡在找invisible coat,将它转变成找标签的问题。Reverse Proxy就是这个标签,水下的冰山却是invisible coat。

Suggestions ?

除此之外,还有什么旁门左道可以使用?欢迎分享。

Secrecy is over-rated, when Google is your proxy.

更新:WordPress的Feed把span标签去掉了,订阅器里无法看到测试效果,请直接访问文章页面。

Author: 店长

The Master of BitInn

40 thoughts on “A few ideas for your Proxy 2.0”

  1. 其实“正太什么的最讨厌了,萝莉万岁!”才是所要表达的,同时骗过了机器和只看表象人,除非机器自动忽略了HTML标签。

    1. 请不要混淆视听……尽管这个站支持“萝莉万岁”,但例子要表达的是“正太万岁”。“萝莉万岁”是camouflage。

  2. 开放更多TLD并不会带来任何好处。tg封过n多tld了。由于DNS协议的公开性,只需要封锁一个tld的递归解析 root,所有这个tld下的域名都 bye bye

    And encryption is not answer to everything, approximate logic handshake FTW!

    1. Only if TLDs are small enough to be bullied ? the sole international case I know of is .tk (Which is accessible with Public DNS, but then changing DNS might be too “technical” for the masses)

      1. > changing DNS might be too “technical” for the masses

        It’s already happening, because ISP DNS hijacking and the Wall spoofing. Sooner or later there will be significant change in three criteria: IP/DNS/Content. We just too focused on Content now.

      1. IMHO, if the DNS is damaged completely by TG, there will be alternative DNS both system and protocol, then domain names will be free. It’s called pseudo domain, like .onion, .i2p, .fr**net

  3. 店长说的是内容提供者要做的
    而阅读者常用的那几款 Proxy 软件的生命周期太短,即使新版及时跟进
    在旧版失效的前提下获取新版似乎是个悖论
    Secure Shell 或 VPN 又对使用者的水平有一定要求
    能够解除网络故障的人毕竟是少数,有些人虽然知道有这回事
    但在一个全新环境中就只能跪求别人发文件了
    以现在的网络环境来看,中华人民共同和谐国迟早变成西部某自治区的现状

  4. 需要明确的是,本文讨论的技术的作用只限于让应用层内容变得machine-unreadable从而避免90秒rst,对于人工审查是无效的。因此我人为对抗一般性的内容审查,最好的办法是基于身份认证的“软”访问控制——对不同的人显示不同的内容,而无明显的“拒绝访问”提示,本质是伪装。

    gfw是“算法中心化”的,让它最头疼不是应对一种公开的高强度协议而是处理各种各样的土制的和非公开的算法(很赞同“security < obscurity”,在这种情景下的。

    @virushuo提出的加密方案更多是趣味性的(蛋疼)和抛砖引玉,比如钓出店长这篇文章w。因为网页加密现在对于gfw来说作用不大,gfw很少做深度检测(性能问题)。

    本文讨论的理论的直接应用就是phproxy之类的网页代理吧,不过它们现在最大的问题是协议兼容性和支持富媒体,加密倒不是大问题了。

      1. 只有“基于身份认证的软访问控制”能够“绕过人工审查”,因为如果你能看到则审查者也能看到。“软”的作用是让审查者无法意识到收到访问控制的意思。

  5. 是一个思路,竖排文字,火星文,都可以使用。

    最终的有效成果大概应该是一个混合了很多思路的办法。

  6. 很少做深度检测,这是确实。我也赞成 obscurity 优先。

    之所以我选rsa下手,是想看看变态能变态成什么样….当然如果能搞到一个可接受的效率,也是可以实用的。

  7. ”能上“和”上好“是两码事……只上我会选择能上这一说。

    那个HTML code有点鱼目混珠的感觉,果然能骗过表象的人。不过订阅的时候就直接跳出全部的文字了,果然reader不这么好骗过么?

    PS:看到#1的头像以为自己穿越了

    1. 如果reader能解析feed输出的html标签那这个问题应该能够解决。(若无其事装状地飘过

  8. 我是外行~不过设想过类似P2P的方法,不是类似tor的,而是直接是一个P2P的虚拟服务器,但这样只能在万不得已的情况下……

  9. 我以前也想过使用HTML标签分割来躲避关键字屏蔽,不过最终由于这样会产生较多垃圾代码增加消耗而放弃…更进一步,也许可以用绘图将文字转换成图片-__-

  10. 将文字直接转换成二维码,让读者自行解读是否也会是个途径?
    但,如同天朝古训:道高一尺,魔高一丈;一山自有一山高。一旦站点热起来,必定被衙役们关照。

  11. Security or Obscurity, 我选择前者. 防止中间人攻击唯一方法是公匙证书. 这个证书可以是CA认证的; 或是你自己可以保证安全的, 如自用SSH的公匙. 所以对在下这样极端重视安全人来说, 其它的方式都被无视了.

    Security through obscurity为什么没戏? 这是一个trick(花招). 信息系统理论里破解trick的平均成本与代价远远低于破解工业标准的安全技术. 不要小看我们的对手. Big brother is watching you.

  12. 反向思考一下,也许可以(很欠):强力插入国内节点,复制国家IDS操作进行无差别随机攻击,将网民正常使用一切网络服务的门槛提高到墙高,同时不忘宣示国家墙的存在性,逼迫国家选择网络安全性(比如提早部署IPv6等)而非可控制性,或者至少放任民众翻墙。同时改变网民的技术生态,我记得现有的加密手段比如RSA尚无法破解,这几十年不存在被攻破的可能性,只要消除不安全手段的成本优势,普遍的安全手段也许可以打败墙。

  13. 把feed下下来看了一下,里面是description标签和content:encoded标签两种都有的。只是大多数阅读器是识别或者优先识别description……我用的NewsFox则是优先认content:encoded的

Comments are closed.