Been using Rackspace hosted email for a year now. One thing I can be certain: fantastic support! Unlike other vendors, Rackspace associates know what they are doing. Goods: High Reputation IPs; Very Reliable; Not blocked in any counties (Google Apps blocked in Mainland China); Amazing Spam filtering. We were using Tencent Bizmail, one noticeable change…

I have noticed even people who claim everything is predestined, and that we can do nothing to change it, look before they cross the road. -Stephen William Hawking  

You may not like the result, but this is how democracy works. Bad day.

Justice Must Not Only be Done, but Must be Seen to be Done

无论是在论坛也好，在其他人的博客也好，总是有人希望批判现有的标准，然后提出一个自己来的版本。有些是很有建设性的，但是有些言论感觉就是他们自己对这个标准都一知半解就在批判。 SSL便是其中一个热点。 作为现代网站的标配，SSL已经经历若干版本，AES已经加入到Intel指令集，特别是HTTP2支持连接复用已经基本使SSL不再拖慢加载，TLS1.3将会进一步优化其效率。 那么，有人就开始说SSL的优化方案： 1.SSL没有意义： “用一个JS可以解决的事情，何必？” JS的确可以对流量进行加密，但是不是全加密，也不能保证被加密。 1.把加密从协议层移到应用层。JS的加载便只能在HTML开始时才能运行；其次路径和文件名在传输中会导致明文；这个还是不是最严重的。 2.最严重的是SSL除了encryption还有integrity check. SSL全加密意味着man-in-the-middle无法知悉传递的具体数据，也就无从更改其数据。而JS加密方案，其JS加密必然是基于HTTP，这样JS就有可能被劫持，一个中间服务器可以对数据进行解密，然后再加密发送给客户，客户完全不知道自己信息已被获取。（HTML Check-sum也不能避免这个问题）。 3.即使是JS有一套可行的Key-Exchange，但是没有一个CA作为担保，又怎么能确定Key-Exchange is done right? PS.这其实既是现有的 Chain of Trust的优点（缺点在下文说）。操作系统/浏览器厂商维护一个可信CA列表，所以普通用户就可以直接使用一个经过Audit的CA列表，不需要像PGP一样由用户手动维护一个列表（假设一个普通用户没有经历和足够的知识去鉴定一个CA的可靠性）。这样操作系统/浏览器再验证证书的时候就只需要从内置证书中去对网站证书进行验证，就可以知道网站发送的证书到底是不是Valid and Trusted 的。JS则不然（当然，除非你有浏览器插件或者客户端软件来鉴定），JS在HTTP下很难防止Reply Attack（这里加一句，以前腾讯是有过md5(password, uin, vcode)大概这样的方法,其中vcode是图片验证码，其实想法是不错，在12年的时候估计快速破解还有问题，但是现在验证码的识别完全可以是人工加自动识别的方式，现在一个人工识别平台的响应速度可以在180秒左右，而且成功率几乎100%，所以这个方式在现在也没有什么作用，就算在当时也可以在传输过程改JS，指示浏览器POST用户名密码到我的服务器上）和 Man-in-the-Middle Attck. 这个方案如果在HTML在SSL的情况下也许还有可行性，但是既然已经引入了HTTPS，何不一起用上呢？ 令人诧异的是，这个方案即使是一些国内大公司也在使用。 JS加密之所以存在更多是因为Client Side Auditable， 方便网站做Browser Based Encryption and Decryption，来消除客户的隐私怀疑。 PS.现在的证书那么便宜，Comodo我11刀可以拿到三年，Let’s Encrypt更是永久免费，SNI Support现在也不再是一个大问题了，何必不使用aduited的方案呢。   我觉得与其讨论是否使用SSL还不如去研究Centralized Trust，Google提出的CT和现在现行的针对CA的Punishiment也许已经很好了，但是像iOS这样居然不能让用户自己Revoke Root CA的做法我觉得还是欠妥。 HPKP是一个较好的解决方案去防范乱签发，但是也要是客户第一次访问就访问到正确服务器的情况下。而CT的话，上游完全可以针对性的阻止一个CT request至CT Log Server。要比较彻底解决这个 potential flaw我认为应该有一个 public org that…

简单介绍一下背景： 一台WVR450G V3.0做主路由； 一台WVR450G V2.0做备份； 最近光改，速度一直上不到100M 只能在10M左右，一开始以为是光衰，机房端口限制，毕竟这两个路由都是千兆路由，想着百兆吞吐量肯定有吧。 结果什么问题都试过了，只剩下一个路由，查了一下官网，丝毫没有说吞吐量，只是不断强调是千兆路由: 3×3 MIMO架构，无线传输速率高达450Mbps 直到最后连接主机测试的时候才发现光猫什么都可以，就是路由器出问题。 我也就不多说什么了，偷换概念的宣传也是令人吃惊。 Cisco设备价格虽然是比较高，但是一台100M交换机，25个口，全部插满，内网速度还是12MB/S，日常根本就不会有任何问题，无论丢包还是延时都无懈可击。实打实的产品。 这次学乖了，以后尽量不买国产，两台WVR450G也买了有1000，结果令人失望。 这次买了Mikrotik RB2011UiAS-2HnD-IN，官网规规矩矩的给出不同情况的网络吞吐量（我们网络的Avg Package Size是576 bytes，所以即使在大负荷情况下100M也不会有什么问题。） 买了之后，导入了规则，100M还是毫无压力。 有时候，明明想支持国货，但国货却不断让你失望。

If we don’t believe in freedom of expression for people we despise, we don’t believe in it at all. –Noam Chomsky

People are sharing links for petition on their WeChat moments talking about how unfair Mr. Peter Liang’s case was. Indeed, the case is unusual, a police officer accidentally shot an unarmed civilian who wasn’t engage in any type of crimes; a NYPD officers who was found guilty relating police shooting for a decade. However, we…

现在流量模式识别能力越来越强，由于维护的网络要求大量的外网流量，所以其实现在的稳定快速的方法除了混淆之外就是堆钱买线路和IP了。之前的承载服务器只需要两台，现在已经有超过5台服务器和10多个IP，而且是不同机房的网络才能稳定地承担流量了，成本还挺高。如果不是走企业级的QoS线路的话估计这个数量还不够。

怎么说呢，我选机房的时候都是先看BGP的Peers然后再决定的，但是即使这样也进了不少坑。 首先，我真心不推荐CN2去走Digital Ocean和Ramnode的线路，真的是有挺多问题的,都是那些Peer策略的原因吧。 好机房有OVH,HE,和其他一些机房。 但是最近微林出了HK线路，转发效果对我手上的所有机房都极好，虽然转发价格比CN2线路高一倍，但是我个人觉得还是值的。 PS.博客是在OVH机房，用了CF。