ACGEP Homepage

我不能让技术宅猖狂下去了。

要是DVD有配音补白就好了（傻笑），话说有DVD版修改配音的先例么，在剧情不变的情况下？

image via cats-blog

近日在网络传得比较离谱的一条消息是对TLS/SSL应用层的窃听。随着瓷翁生日的临近，长城似乎有越蹦越高的趋势，导致不少人对SSL v3的安全性也产生了怀疑，这里客栈尝试用简短的图文解释一下所谓的窃听如何完成，以及通过什么方式避免。

首先要强调的是，目前没有对SSL v3这个安全协议的可行攻击；所有窃听均需利用客户端（浏览器及用户）的弱点执行，而非对协议本身的直接攻击。

So, in before the fear spreads…

SSL会话破解有三种主要方式：一是通过嵌入系统获取密匙，二是通过巧妙的方式进行Cryptanalysis（密码分析），三是设立中间人执行MITM攻击。

假如攻击者能入侵用户主机或服务器，那用户资料就直接沦为刀俎了，再绕道SSL属于白费力气。因此保持个人系统安全对防止第一类“破解”尤为重要。攻击者并不是在破解SSL协议，而是在直接想办法和你的系统挂钩，盗取加密前和解析后的信息。

本地分析加密会话很简单，类似Http Analyzer的软件支持IE，Firefox，Chrome和Safari几款浏览器的请求记录，它们是站在用户与浏览器之间的看客，而非本地与远程主机之间的黑客（对于不支持的软件，例如Opera或Putty，它是无法记录HTTPS请求的）。

第二种方式因缺乏有效的密码分析，并没有实际应用；SSL v3本身没有已知漏洞，解开会话需要利用客户端和服务器端的漏洞完成（获取密匙）；等同第一类攻击了。

相比之下，最可行的SSL窃听方式是第三类：通过MITM。无需获得密匙，无需本地木马，远程窃听者通过建立两条链接：一条从窃听对象到窃听服务器，另一条从窃听服务器到目的服务器，尝试偷换身份并做到会话窃听。

之前我们也说了，协议本身并没有漏洞，因此浏览器的安全设计和用户的安全意识就成了最受考验的部分。第三类攻击要生成不合法的证书，当今的浏览器在遇到该类证书时都会提示错误，但信息的表达方式各不相同，误导用户接受非法证书也时常发生。

Chrome 3-beta的警告是最显眼的。

Firefox 3.5的警告需要阅读，也算显眼的。

Opera 10的警告包含有用信息，但未必能帮助分析。

Safari 4 on Windows的警告和普通提示没什么区别，一点就过了……

IE7的警告够简洁，但解释不足。不知道IE8如何（安装不能，无法测试）。

IE6的警告有够误导，以多数票计算，这是可以接受的对吧？

为了更好地测试各浏览器在MITM攻击下的反应，这里使用Stanford教学用的简单SSL MITM Proxy来测试。具体设置如下：

先准备好浏览器与Java。下载工具并解压压缩包后，使用命令行工具，转到该目录，并输入以下命令（Linux用户请看Readme）。

java -cp iaik_jce.jar; mitm/MITMProxyServer -localHost localhost -localPort 8001 -outputFile output.txt -keyStore FakeCAStore -keyStorePassword passphrase -v

这样就会在本地设立一个窃听用的Proxy，它会尝试修改所有加密链接发送的证书，将自己寄生在加密连接上。（注意该Proxy并不需要安装在本地，它可以安装在信息途经的任意服务器上，包括任何Tor节点。）

配置浏览器使用这个代理（localhost:8001），模拟请求通过远程的窃听服务器。和目的服务器配上之后，Proxy就会接收原证书，并制造假证书发送给浏览器，这时浏览器应该提示错误。

假如用户选择接受该证书，则余下的通信可被监听，这些通行将被记录在本地的output.txt，各位可自行瞻仰其详尽程度。

如果你看到的传输内容是一大串数字，请看Encoding是否启用了gzip，那是gzip后的网页数据；Amazon不启用gzip，直接返回HTML代码。

一个简单的SSL窃听就是这样完成的。但如何防止呢？

I. 认真检查URL——这是废话，但也是最致命的用户疏忽。

II. 不要接受非法证书——当前用户关注度不足。

尤其是在存放了个人信息的网站。例子中的非法证书替换了发行者的部分（替换为locahost和stanford），是非常好辨认的错误。实际应用中，普通用户将很难分辨证书的真伪，这时选择拒绝才是上策，不管你有多信任该网站。

对于部分没有证书却强迫使用HTTPS的网站，请避免提交任何涉及个人隐私的信息，以免发生意外（接受非法证书将建立未验证的加密连接，用户和网站都没有办法判断是否有人窃听该链接）。

最后是检查CA机构，CA机构告诉浏览器是否应该相信一个网站：假如你不信任签发证书的那家CA，那它验证的网站你也不应相信（浏览器均内置了CA列表，但根据浏览器的不同，它们支持的CA数量也略有不同）。

III. 不要允许SSL v1和v2——过期的SSL版本。

SSL v1和v2都有已知漏洞，不要允许浏览器降至这两个级别。主流浏览器都有禁止老加密协议的选项。

IV. 使用现代化的浏览器——你想要安全，却继续使用IE6核心？

有些网站存在HTTPS与HTTP混用的问题，这时要小心拦截。虽然无法在远程修改被加密的对象，但未加密对象是可以修改的；若有攻击者插入隐藏表格或JS代码，数据可能被提交至第三方服务器，而用户不会察觉曾被窃听。IE7+会提醒用户有关“安全与不安全内容同时存在”的问题。

（我发现Opera 10和Safari 4都比较沉默，不会提示“存在未加密对象”，是我没设置对还是它们不受影响就不清楚了。）

实际应用中，由于SSL窃听十分耗费资源，是无法大规模长时间实施的；若你在浏览时经常碰到证书错误的情况，请尝试换用浏览器以排除软件上的错误。若情况继续，祝君好运……话说回来，收买CA机构也许比购买窃听服务器便宜得多；所幸咱们这边没什么大型的CA机构，否则……

大体的解释就这么多了，欢迎留言指教。

完。

旧番一个个的结束，没结束的也大多没JQ没欢乐……我对这青黄不接的日子绝望了！

开门见山，前情不表（本来这俗烂的故事也没啥前情|||）

我总觉得我把男主（小受）的性格完全崩坏了orz，原作里明明是个蠢良的孩子啊！为啥给我拗成了腹黑？

放课后的屋顶是午餐逃课打架……同时也是打野战常用场地，偶尔被凉宫之流用来拍拍小电影。

事实证明，自残这种苦肉计只有在对方对你还有那么点意思的时候用，不然的话，你就是耐着性子把自己凌迟了也没用。

按照s1的统计数据，动画里“幼馴染み”（和之后横档一杠子的角色相比）胜出的比例有70%，柯南蓝青双恋君吻初音岛俏房客……饶是True Tears中养鸡女人气如此之高，但最终官方还是把最终战的桂冠出人意料（？）的戴到了养女头上，除了海蟑螂的后宫生活那种不按牌理出牌的片子，“幼馴染み”属性似乎已然是不可挑战的存在其他CP爱好者们还是洗洗睡吧——

不过上面那段其实只是借口。
内幕是这样的——

于是，主线砍掉重来。

温泉场面如果没有杀必死就是监督失格！

虽然是非常老土的“小时候可爱到令人忍不住暗自立下婚约的萝莉长大后发现居然是个男的！”设定，但在同人女老妈的故意安排下（没错！我坚持认为这老妈是故意的！），生搬硬套到“幼馴染み”设定上后，即便是大罗金仙也无逆天之力了。 （众：这到底是幼馴染み还是强买强卖啊！）

但是如果到这里就HE的话，显然对不起制片人，为了撑满25分钟，不得不硬塞进去一些妨碍男男主人公LOVELOVE的反面角色来起到迂回（=拖延）的作用

剧情进展到这里，已经没有多余的经费拍摄华丽丽的战斗场面了，反正那种事情参照高达削人棍之类的脑补就可以了，于是还是直接跳到结尾就可以了，相信善良的群众只要有了HE就不会对过程斤斤计较的。

其实傲娇老爸还是很萌的，就是戏份（=经费）太少了……

The essence of internet censorship is to disrupt any convenient methods for consuming or exchanging information that is unbound by governmental regulation, and to further convey the presence of pervasive surveillance. – Anon

中国男篮是彻底输给了伊朗，但伊朗人的雕虫小技在我们眼里仍是笑话。期待五星红旗高挂之日！