179 评论

扫盲 HTTPS 和 SSL/TLS 协议[2]:可靠密钥交换的难点,以及身份认证的必要性

★先插播一个安全通告


  说来凑巧,就在本系列刚开播之后没几天(11月11日),微软爆了一个跟 SSL/TLS 相关的高危漏洞影响【几乎所有的】Windows 平台。至此,【所有】主流的 SSL/TLS 协议栈(至少包括:开源的 OpenSSL、开源的 GnuTLS、微软的 SSP、苹果的 SecureTransport),全都在今年爆了高危漏洞。看来俺这个系列生逢其时啊!
  个人觉得:【2014年】必将在信息安全历史上留下醒目的记录。
  用 Windows 系统的同学,这几天要尽快升级微软的“安全更新”。因为该漏洞会导致“远程代码执行”,非常危险。
  (微软的公告中没有提及 Win2000 和 WinXP 是因为这俩已经过了“产品支持周期”。【不】等于说这俩没问题)


  在本系列的前一篇,已经介绍了相关的背景知识以及设计 SSL 需要考虑的需求。当时俺提到:设计 HTTPS 的最大难点(没有之一)是——如何在互联网上进行安全的“密钥交换”。今天就来讲讲密钥交换的难点和解决方法(暂不谈技术实现)。


★方案1——单纯用“对称加密算法”的可行性


  首先简单阐述一下,“单纯用对称加密”为啥是【不可行】滴。
  如果“单纯用对称加密”,浏览器和网站之间势必先要交换“对称加密的密钥”。
  如果这个密钥直接用【明文】传输,很容易就会被第三方(有可能是“攻击者”)偷窥到;如果这个密钥用密文传输,那就再次引入了“如何交换加密密钥”的问题——这就变成“先有鸡还是先有蛋”的循环逻辑了。
  所以,【单纯用】对称加密,是没戏滴。


★方案2——单纯用“非对称加密算法”的风险


  说完“对称加密”,再来说说“非对称加密”。
  在本系列的前一篇谈“背景知识”的时候,已经大致介绍过“非对称加密”的特点——“加密和解密采用【不同】的密钥”。基于这个特点,可以避开前面提到的“循环逻辑”的困境。大致的步骤如下:
第1步
网站服务器先基于“【非】对称加密算法”,随机生成一个“密钥对”(为叙述方便,称之为“k1 和 k2”)。因为是随机生成的,目前为止,只有网站服务器才知道 k1 和 k2。

第2步
网站把 k1 保留在自己手中,把 k2 用【明文】的方式发送给访问者的浏览器。
因为 k2 是明文发送的,自然有可能被偷窥。不过不要紧。即使偷窥者拿到 k2,也【极难】根据 k2 推算出 k1(注:这是由“非对称加密算法”从数学上保证滴)

第3步
浏览器拿到 k2 之后,先【随机生成】第三个对称加密的密钥(简称 k)。
然后用 k2 加密 k,得到 k'(k' 是 k 的加密结果)
浏览器把 k' 发送给网站服务器。

由于 k1 和 k2 是成对的,所以只有 k1 才能解密 k2 的加密结果。
因此这个过程中,即使被第三方偷窥,第三方也【无法】从 k' 解密得到 k

第4步
网站服务器拿到 k' 之后,用 k1 进行解密,得到 k
至此,浏览器和网站服务器就完成了密钥交换,双方都知道 k,而且【貌似】第三方无法拿到 k
然后,双方就可以用 k 来进行数据双向传输的加密。

  现在,给大伙儿留一点【思考时间】——你觉得上述过程是否严密?如果不严密,漏洞在哪里?



































  OK,现在俺来揭晓答案(希望你没有事先偷看)
  “方案2”依然是【不】安全滴——虽然“方案2”可以在一定程度上防止网络数据的“偷窥/嗅探”,但是【无法】防范网络数据的【篡改】。
  假设有一个攻击者处于“浏览器”和“网站服务器”的通讯线路之间,并且这个攻击者具备“【修改】双方传输数据”的能力。那么,这个攻击者就可以攻破“方案2”。具体的攻击过程如下:

第1步
这一步跟原先一样——服务器先随机生成一个“非对称的密钥对”k1 和 k2(此时只有网站知道 k1 和 k2)

第2步
当网站发送 k2 给浏览器的时候,攻击者截获 k2,保留在自己手上。
然后攻击者自己生成一个【伪造的】密钥对(以下称为 pk1 和 pk2)。
攻击者把 pk2 发送给浏览器。

第3步
浏览器收到 pk2,以为 pk2 就是网站发送的。
浏览器不知情,依旧随机生成一个对称加密的密钥 k,然后用 pk2 加密 k,得到密文的 k'
浏览器把 k' 发送给网站。
(以下是关键)
发送的过程中,再次被攻击者截获。
因为 pk1 pk2 都是攻击者自己生成的,所以攻击者自然就可以用 pk1 来解密 k' 得到 k
然后,攻击者拿到 k 之后,用之前截获的 k2 重新加密,得到 k'',并把 k'' 发送给网站。

第4步
网站服务器收到了 k'' 之后,用自己保存的 k1 可以正常解密,所以网站方面不会起疑心。
至此,攻击者完成了一次漂亮的偷梁换柱,而且让双方都没有起疑心。

  上述过程,也就是传说中大名鼎鼎的【中间人攻击】(洋文叫做“Man-In-The-Middle attack”,缩写是 MITM)。
  “中间人攻击”有很多种“类型”,刚才演示的是针对“【单纯的】非对称加密”的中间人攻击。至于“中间人攻击”的其它类型,俺在本系列的后续博文中,还会再提到。

  为了更加形象,补充两张示意图,分别对应“偷窥模式”和“中间人模式”。让你更直观地体会两者的差异。
不见图 请翻墙
不见图 请翻墙


★方案2失败的根源——缺乏【可靠的】身份认证


  为啥“方案2”会失败捏?
  除了俺在图中提到的“攻击者具备篡改数据的能力”,还有另一点关键点——“方案2缺乏身份认证机制”。
  正是因为“缺乏身份认证机制”,所以当攻击者一开始截获 k2 并把自己伪造的 pk2 发送给浏览器时,浏览器无法鉴别:自己收到的密钥是不是真的来自于网站服务器。
  假如具备某种【可靠的】身份认证机制,即使攻击者能够篡改数据,但是篡改之后的数据很容易被识破。那篡改也就失去了意义。


★【身份认证】的几种方式


  下面,俺来介绍几种常见的“身份认证原理”。

◇基于某些“私密的共享信息”


  为了解释“私密的共享信息”这个概念,咱们先抛开“信息安全”,谈谈日常生活中的某个场景。
  假设你有一个久未联系的老朋友。因为时间久远,你已经没有此人的联系方式了。某天,此人突然给你发了一封电子邮件。
  那么,你如何确保——发邮件的人确实是你的老朋友捏?
  有一个办法就是:你用邮件向对方询问某个私密的事情(这个事情只有你和你的这个朋友知道,其他人不知道)。如果对方能够回答出来,那么对方【很有可能】确实是你的老朋友。
  从这个例子可以看出,如果通讯双方具有某些“私密的共享信息”(只有双方知道,第三方不知道),就能以此为基础,进行身份认证,从而建立信任。

◇基于双方都信任的“公证人”


  “私密的共享信息”,通常需要双方互相比较熟悉,才行得通。如果双方本来就互不相识,如何进行身份认证以建立信任关系捏?
  这时候还有另一个办法——依靠双方都信任的某个“公证人”来建立信任关系。
  如今 C2C 模式的电子商务,其实用的就是这种方式——由电商平台充当公证人,让买家与卖家建立某种程度的信任关系。
  考虑到如今的网购已经相当普及,大伙儿应该对这类模式很熟悉吧。所以俺就不浪费口水了。


★如何解决 SSL 的【身份认证】问题——CA 的引入


  说完身份认证的方式/原理,再回到 SSL/TLS 的话题上。
  对于 SSL/TLS 的应用场景,由于双方(“浏览器”和“网站服务器”)通常都是素不相识滴,显然【不可能】采用第一种方式(私密的共享信息),而只能采用第二种方式(依赖双方都信任的“公证人”)。
  那么,谁来充当这个公证人捏?这时候,CA 就华丽地登场啦。
  所谓的 CA,就是“数字证书认证机构”的缩写,洋文全称叫做“Certificate Authority”。关于 CA 以及 CA 颁发的“CA 证书”,俺已经写过一篇教程:《数字证书及 CA 的扫盲介绍》,介绍其基本概念和功能。所以,此处就不再重复唠叨了。
  如果你看完那篇 CA 的扫盲,你自然就明白——CA 完全有资格和能力,充当这个“公证人”的角色。


★方案3——基于 CA 证书进行密钥交换


  其实“方案3”跟“方案2”很像的,主要差别在于——“方案3”增加了“CA 数字证书”这个环节。所谓的数字证书,技术上依赖的还是前面提到的“非对称加密”。为了描述“CA 证书”在 SSL/TLS 中的作用,俺大致说一下原理(仅仅是原理,具体的技术实现要略复杂些):
第1步(这是“一次性”的准备工作)
网站方面首先要花一笔银子,在某个 CA 那里购买一个数字证书。
该证书通常会对应几个文件:其中一个文件包含公钥,还有一个文件包含私钥。
此处的“私钥”,相当于“方案2”里面的 k1;而“公钥”类似于“方案2”里面的 k2。
网站方面必须在 Web 服务器上部署这两个文件。

所谓的“公钥”,顾名思义就是可以公开的 key;而所谓的“私钥”就是私密的 key。
其实前面已经说过了,这里再唠叨一下:
“非对称加密算法”从数学上确保了——即使你知道某个公钥,也很难(不是不可能,是很难)根据此公钥推导出对应的私钥。

第2步
当浏览器访问该网站,Web 服务器首先把包含公钥的证书发送给浏览器。

第3步
浏览器验证网站发过来的证书。如果发现其中有诈,浏览器会提示“CA 证书安全警告”。
由于有了这一步,就大大降低了(注意:是“大大降低”,而不是“彻底消除”)前面提到的“中间人攻击”的风险。

为啥浏览器能发现 CA 证书是否有诈?
因为正经的 CA 证书,都是来自某个权威的 CA。如果某个 CA 足够权威,那么主流的操作系统(或浏览器)会内置该 CA 的“根证书”。
(比如 Windows 中就内置了几十个权威 CA 的根证书)
因此,浏览器就可以利用系统内置的根证书,来判断网站发过来的 CA 证书是不是某个 CA 颁发的。
(关于“根证书”和“证书信任链”的概念,请参见之前的教程《数字证书及CA的扫盲介绍》)

第4步
如果网站发过来的 CA 证书没有问题,那么浏览器就从该 CA 证书中提取出“公钥”。
然后浏览器随机生成一个“对称加密的密钥”(以下称为 k)。用 CA 证书的公钥加密 k,得到密文 k'
浏览器把 k' 发送给网站。

第5步
网站收到浏览器发过来的 k',用服务器上的私钥进行解密,得到 k。
至此,浏览器和网站都拥有 k,“密钥交换”大功告成啦。

  可能有同学会问:那么“方案3”是否就足够严密,无懈可击了捏?
  俺只能说,“方案3”【从理论上讲】没有明显的漏洞。实际上 SSL 的早期版本(SSLv2)使用 RSA 进行身份认知和密钥交换,其原理与这个“方案3”类似。
  但是,“理论”一旦落实到“实践”,往往是有差距滴,会引出新的问题。套用某 IT 大牛的名言,就是:In theory, there is no difference between theory and practice. But in practice, there is.
  所以在本系列的后续博文,俺还会再来介绍“针对 SSL/TLS 的种种攻击方式”以及“对应的防范措施”。


★关于【客户端证书】的补充说明


  前面介绍的“方案3”仅仅使用了“服务端证书”——通过服务端证书来确保服务器不是假冒的。
  除了“服务端证书”,在某些场合中还会涉及到“客户端证书”。所谓的“客户端证书”就是用来证明客户端(浏览器端)访问者的身份。
  比如在某些金融公司的内网,你的电脑上必须部署“客户端证书”,才能打开重要服务器的页面。
  由于本文主要介绍的是【公网】上的场景,这种场景下大都【不需要】“客户端证书”。所以,对“客户端证书”这个话题,俺就偷个懒,略过不提。


★总结


  在本文结尾,来稍微总结一下:
  如果没有引入某种身份认证机制,必定会导致“中间人攻击”。这种情况下,加密算法搞得再强大,也是然并卵。
  本文介绍了两种身份认证的思路,分别是:
1、基于私密的共享信息;
2、基于双方都信任的公证人。
  前者【不】适合用于互联网通讯,所以必须采用后者。也就是如今广泛使用的 CA 证书体系。CA 就是上述所说的“双方都信任的公证人”。

  下一篇,扫盲几种“密钥交换协议的算法”。

回到本系列的目录
版权声明
本博客所有的原创文章,作者皆保留版权。转载必须包含本声明,保持本文完整,并以超链接形式注明作者编程随想和本文原始地址:
https://program-think.blogspot.com/2014/11/https-ssl-tls-2.html?m=0

179 条评论

  1. 回复
    1. 幾天不見回應,我還以爲博主神祕失蹤了!
      生病了或到底在忙啥?

      虛驚一場!

      删除
    2. 生病了都不可以说吧,
      只要查一查 (看医生, 请假) 纪录就找到他出来了

      删除
    3. TO 1单元的网友
      因为俺不是全职在维护这个博客,所以就没办法做到每天都上来回复评论。

      有时候俺可能因为太忙,会连续一周都没有上来。
      但是只要不超过2周,应该都还是正常的。
      如果超过2周,那就有可能是俺出事了。

      至于俺在忙些啥,当然不能告诉你太详细的内容。
      因为党国的走狗也在时刻盯着这里。
      俺不想暴露自己太多的信息量。还望谅解 :)

      删除
    4. TO v499
      看来你的安全意识还是比较强 :)

      如果俺真的是生病,并且在博客上透露。
      那么这个行为就会包含若干“俺本人的信息量”。
      如果这种行为重复太多次数,这些暴露出来的信息量经过不断累积,最终会导致俺本人的身份被定位。

      所以,俺顶多只是说“最近太忙”。
      即使有的时候并不是很忙,俺也会这么说 :)
      红楼梦有云:【假作真时真亦假】

      删除
    5. "党国的走狗也在时刻盯着这里"
      希望他们有看光这里的文章啊
      觉醒啊 xDDD

      删除
    6. TO v499
      党国的走狗里面,有不同的人。
      有些人是被洗脑的,有些人则很清楚官方的宣传都是忽悠的。

      在那些【没被】洗脑的人里面,依然有人愿意去替党国卖命。
      比如为了钱,为了名,为了权,为了 XXX
      这样的人,在安全圈内就有不少;
      在俺周围,也有不少

      曾经有读者在博客留言中问俺,为啥不肉身翻墙?在国外也一样可以写博客。
      当时俺回答了几条理由。其中一条是:
      身处天朝这样一个奇葩的国家,每天都看到很多奇葩的事情。
      这就是俺长年写这个博客的动力啊。

      删除
  2. 先占位 回头看……

    回复删除
  3. 最近Wordpress.com主站和在上面搭建的博客都可以用HTTPS方式直接访问了。bit.ly和它跳转的网址bitly.xxx也一样。

    回复删除
    回复
    1. 额,写错了,是bit.ly/xxxxx

      删除
    2. TO 3楼的网友
      俺也盼着 Blogspot 早日提供全程 HTTPS 加密。
      如今 Blogspot 只在后台管理界面提供 HTTPS,博客页面没有

      以 Google 的能力,提供这个应该只是小菜一碟。

      删除
    3. Cloudflare都向网站免费的提供了...
      他们说AES有AES-NI硬解
      用了ECC certs和openssl 1.0.2
      [blahblahblah]...
      就是跟普通的HTTP流量承载没有分别
      google啊~

      删除
    4. 3单元:你认为Cloudflare的反向代理向外提供SSL是安全的解决方案吗?

      删除
    5. 至少也比直接的裸跑HTTP安全
      (另外可以全程https [strict ssl])
      https://support.cloudflare.com/hc/en-us/articles/200170416

      删除
    6. 5单元:你觉得不Strict的SSL有意义吗?Strict SSL就安全吗?
      问题的实质是Cloudflare本身就是在进行中间人,或者说只差了“攻击”两个字。
      流量在Cloudflare的服务器集群上是明文。

      此外我还不知道cloudflare这样做是否支持客户端证书认证。对于有些应用来说这也是重要的问题。
      毕竟配置ssl是在cloudflare的服务器上进行的了。

      删除
    7. 等待大公司推出某个功能这还是黑客的作风吗?痛心疾首啊

      删除
    8. 博主一直稱自己爲“Geek“,但是又要等谷歌施舍HTTPS,這確實有些諷刺啊!
      (真正的黑客/Geek都是敢於挑戰和樂於解決問題的,等別人的施舍實在是褻瀆“黑客”的精神)

      就找不出一個能抗DDOS且支持HTTPS加密的博客平臺代替Blogger嗎?

      删除
    9. google阵营现在用的是ECDHE_RSA作为密匙交换机制,不知道这个比SHA1好在哪里。

      删除
    10. 如果自己建立服务器,Google会允许博主用这个域名吗?那就需要去自己购买域名,服务器和证书,用信用卡付款时肯定会透露个人信息。另外申请SSL证书也涉及到身份验证,又一个隐私泄露的可能。

      删除
    11. 現在EFF基金會和一些知名企業合作推出免費的SSL證書頒發機構(CA)“ [url=https://www.letsencrypt.org] Let's Encrypt[/url] ”,可以加密自己的網站了。
      參考原鏈接: http://thehackernews.com/2014/11/lets-encrypt-certificate-authority-to.html
      應該不會涉及到身份驗證的隱私問題了吧?

      删除
    12. 域名、服務器可以用比特幣購買某個離岸公司提供商的啊(比如:瑞典),不受美國法律的管轄自由度相當大。

      骯髒無恥的政客用離岸公司轉移隱匿的巨額資產以掩蓋真相
      公民【在互聯網時代】利用其保護匿名權導出真相以抵抗邪惡的政府

      删除
    13. TO F Architecter
      只是Chrome里没有写出来, 其实是用了SHA256
      似乎是因为AEAD cipher的问题...
      (如chacha20-poly1305 或 aes128-gcm 这些)

      可以看看Cipher Suites部份 https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96

      删除
    14. To v499
      连i2p在最新的0.9.16版本也开始废除SHA1密匙
      并支持以下几种密匙加密
      ECDSA-P256
      ECDSA-P384
      ECDSA-P521
      Ed25519-SHA-512
      话说这里还真是高手云集,三人行必有我师。

      删除
    15. SHA1已经很不安全的了
      连3大浏览器也说在今年尾会开始不信任用SHA1签署的证书
      例如:v2ex.com已经变成了黄色锁头,据说铬在几个版本后就会把他们变成红色锁头

      不过我倒不明白为何google.com可以过关 :o

      删除
    16. 证书商怎么验证申请者身份?有申请过ssl证书的来说明一下吗?

      删除
    17. 我自已经验:comodo和startssl如果都是寄邮件到域名的who.is注册电子邮件那里
      有些(alphassl)就是DNS里+个TXT记录

      删除
    18. TO 8单元的网友
      多谢批评 :)
      目前暂时没有发现更好的博客平台。
      WordPress 虽然功能强得多,但是安全性方面不如 BlogSpot。
      其它一些大公司提供的博客平台,安全性貌似不如 Google
      Google 的安全研究团队,还是很牛。今年有几个非常重要的高危漏洞(包括 Heartbleed)是 Google 的人先发现。
      名气不大的博客平台,俺也不敢用啊。
      至于国内的,从来不在考虑范围之内。

      删除
    19. TO 7单元的网友
      多谢批评 :)
      老实说,最近2-3年,俺的状态已经不是一个”黑客“的状态了。
      如今很多时间都花在这个博客上,没有太多时间再去琢磨技术了。

      TO 某些外行
      这里说的是”黑客“,而不是”骇客“;两者是不同滴,别搞混了。

      删除
    20. TO amstfj
      除了你提到的,申请域名容易暴露身份,还有一个问题就是:自己搭建服务器,多半也要找提供商,同样容易暴露身份。
      虽然可以通过一些技术手段来规避,但终归是增加了一些风险。

      而且考虑到 Google 在安全性方面的强项(参见俺在18单元所说),所以目前一直还是 BlogSpot

      删除
    21. TO 11单元的网友
      前不久,俺也看到新闻说,EFF 开始提供免费的 SSL 证书。
      以 EFF 的人品,应该还是比较可靠的。

      俺没有申请过,不知道操作层面是否”傻瓜化“。
      如果足够傻瓜化,非常有利于 HTTPS 的普及。

      删除
    22. TO 12单元的网友
      多谢分享你的经验 :)
      不过俺要提醒你——比特币的匿名性【并没有】你想像的那么好。
      有空的话,俺专门发一篇帖子聊这个话题。

      删除
    23. TO F Architecter
      俺博客的读者里面,不乏专业的信息安全人士。
      有这些人来捧场,俺很荣幸 :)

      删除
  4. 泱泱14亿中国人里,这么久才出现这么一位编程随想,可以具备如此的胆识、技术和正义感,在昏暗中引亮一盏微弱的灯,让尚有知觉的同胞看到温暖和希望。真不知这是中华民族的万幸还是不幸。
    文章依然相当精彩。
    顺便问下编程兄,什么时候可以实现博客打包电子书里收录评论?很多评论也非常有用。

    回复删除
    回复
    1. TO 4楼的网友
      多谢捧场 :)
      不过你对俺的吹捧,实在不敢当——俺只是一个普通的网民而已。

      另外,
      在天朝之内,还有很多人在默默地做着贡献、承受着巨大的风险、并且不为人所知。
      这样的人更值得尊敬。

      删除
    2. 评论只能自己收录或等博主收录吧。。。如果全部收录的话,有刷屏的,有宗教宣传的,有游戏讨论的,这本书可能就几g了,无关内容比正文都多了。

      删除
    3. 其实我觉得这里的评论比正文更精采
      (正文也很精采啊)

      删除
    4. 呵呵!4樓吹捧得太肉麻了。。。

      要收錄評論的話工作量太大了,怎麽才能自動識別採集高質量的留言呢?
      打包的電子書留給讀者一些修改權限,方便根據自己的情況採集對自己有幫助的留言啊!

      删除
    5. TO 4楼的几位
      关于“博客打包电子书”要如何包含评论,这是一个比较头疼的问题。

      1、全部打包
      实现起来最容易,但是缺点就是——良莠不齐,导致信噪比太差

      2、由俺来手工筛选
      信噪比肯定会好很多,但是俺没有这么多时间(而且评论每月新增几千条)

      3、让用户来手工筛选
      需要对【每一条评论】引入类似“+1 按钮”或“Like按钮”的机制。担心会拖慢页面的加载速度。

      目前俺比较倾向于第三种方案

      删除
    6. 每一条评论控怕被党国的机器故意提升5毛流言评分

      删除
    7. TO 6单元的网友
      +1 按钮 和 Like按钮 需要相应的 SNS 帐号。
      如果党国的走狗采用你所说的策略,恶意刷高某些五毛评论的评分,需要注册好多帐号。
      即使这样干,俺还是有应对的策略——
      可以在 方案3 的基础上,再结合俺的个人审核。
      如果只审核那些评分高的留言,俺的工作量就会小很多。

      删除
    8. 我說的是通過博客的全站搜索把高質量的博文精選出來,
      而不是引入类似“+1 按钮”或“Like按钮”的机制。(這樣不會拖慢頁面加載速度吧)

      删除
    9. TO 8单元的网友
      你提到说:“采用搜索功能来筛选高质量的评论”。

      这个方案存在几个问题需要讨论:
      1、
      由谁来做这个工作?
      如果是俺来做,那么就等同于前面的“方案2”——俺的时间不够用

      2、
      如果是由很多热心读者一起来做,那么如何反馈自己收集的结果?
      俺在“方案3”中提到的“+1按钮”和“Like按钮”,是用来反馈众多网友的喜好

      删除
    10. 由讀者根據自己的情況各取所需嘛!(我在4單元不是提到過了嗎)
      不過打包的電子書要允許讀者更改才行哦

      删除
    11. TO 10单元的网友
      如果让读者自己去修改电子书,对大部分读者而言,难度偏大。

      另外,如果按照你的方案——让读者自己选择。
      那么俺就需要在电子书中包含所有评论。
      但是根据“二八原理”,大部分评论都不具有足够的价值

      删除
    12. 不是有個博客站內搜索嗎?
      讓讀者自己去搜索,然後根據自己的情況刷選整合進去不就行了。

      不過勞煩你又要寫一篇打包電子書的教程和提供腳本了。

      删除
    13. TO 12单元的网友
      电子书内置的搜索功能比较弱。
      而俺博客的”站内搜索“,需要依赖 Blogspot 平台提供的 API,没法【离线】使用,因此也不方便整合到电子书中。

      删除
    14. 博主又誤會我的意思了
      我說的不是把“站內搜索”整合進電子書里,
      而是讓讀者依據自己的情況利用博客的“站內搜索”來刷選高質量的留言內容,收藏整理好打包進電子書里。
      (過程就像在google搜索自己想要的內容,找到後收藏起來同樣道理,應該懂了吧)

      删除
    15. TO 14单元的网友
      多谢提建议 :)
      俺在 13单元 回评论太快,没看仔细,误解你的建议,抱歉 :(

      这个做法从技术上可行。不过也有如下几个问题。
      首先,
      但是如果让每个读者自己去收集好的评论,会浪费大伙儿很多时间。
      其次,
      用”搜索“的方式,来汇总高质量的评论。容易发生遗漏。
      (有些高质量的评论,没有对应上你的搜索关键字,就没被发现)

      还需要再想想,有没有更好的办法?

      删除
  5. 网站购买的数字证书会被偷拿到吗,中间人截获网站发给浏览器的数字证书,不能把数字证书里的公钥换成自己的公钥吗

    回复删除
    回复
    1. CSR 里只有public key, 但CSR都在CA那儿生成就难说了...

      删除
    2. *但假如CSR都在CA那儿生成就难说了

      删除
    3. 我知道了,公钥要公布出来,数字证书保证了公钥不能造假,然后,ca产生的密钥要怎么安全传送给网站呢

      删除
    4. 不太明你想问甚么
      [ca产生的密钥要怎么安全传送给网站]?
      ca产生的密钥: 在CA手中
      (你自已的CSR是用openssl等工具再加上自已的private key造出来的, CA不会知道你的private key)
      安全传送给网站: 是指网站的证书?
      nginx/apache等要用CA给网主的certificate再加上早前自已签CSR的private key, 就可以做HTTPS网站了

      删除
    5. TO 5楼 和 3单元
      估计是同一人吧?

      网站发送到浏览器的“数字证书”,如果中途被篡改,浏览器就会发现证书出问题。
      (大致的原理,本文中有提到)

      删除
    6. 我想错了,公钥密钥当然要网站自己产生,恩模模糊糊知道怎么回事了,脑细胞死了好多,算了又不搞IT

      删除
    7. 或者你的意思是CA怎样把证书发送给站长?

      删除
    8. 对证书招篡改就会被发现不懂,ca吧证书发送给站长,证书中途被偷了 ,小偷用自己的公钥放证书里传给浏览器,浏览器怎么判断证书真伪的

      删除
    9. 通常CA都会要求站长验证域名后才发出证书的
      而且CA和站长的沟通有HTTPS的.

      删除
    10. 都是好问题,不过还是想得多干得少,自己去StartSSL.com上申请个证书就知道了,又不要钱:)

      首先,StartSSL上面为例,公钥-私钥这个密钥对是利用浏览器的API生成的。私钥是在浏览器这里生成的,其实应该可以直接让你保存,不提交给服务器。在其他的应用里面,私钥可以通过openssl的命令生成。然后我记得申请证书可以生成一个CSR(证书签名请求),送给CA去签署。具体CSR包含什么我不知道,但是应该能证明是只有你的私钥才能生成CSR。

      9单元,小偷传给你的证书先不说因为小偷不是CA无法给出等效于CA的签名的问题(这是主要矛盾)——你自己都不知道证书上的公钥不是你自己的吗?就算你不知道,你拿着这个证书去运行服务器,你的签名(服务器用来证明自己的身份的方法)无法用给定的公钥验证啊。

      删除
    11. TO v499 和 冒牌的“忠党爱国”
      多谢替俺回答问题 :)

      删除
    12. [quote=忠党爱国]
      都是好问题,不过还是想得多干得少,自己去 [i]StartSSL.com[/i] 上申请个证书就知道了,又不要钱:)

      首先,StartSSL上面为例,公钥-私钥这个密钥对是利用浏览器的API生成的。私钥是在浏览器这里生成的,其实应该可以直接让你保存,不提交给服务器。在其他的应用里面,私钥可以通过openssl的命令生成。然后我记得申请证书可以生成一个CSR(证书签名请求),送给CA去签署。具体CSR包含什么我不知道,但是应该能证明是只有你的私钥才能生成CSR。

      9单元,小偷传给你的证书先不说因为小偷不是CA无法给出等效于CA的签名的问题(这是主要矛盾)——你自己都不知道证书上的公钥不是你自己的吗?就算你不知道,你拿着这个证书去运行服务器,你的签名(服务器用来证明自己的身份的方法)无法用给定的公钥验证啊。
      [/quote]

      这位 "忠党爱国" 同学所推荐的 [i]StartSSL[/i], 是博主在[url=https://program-think.blogspot.com/2016/09/About-WoSign.html]另一篇博文[/url]中所说的, 在党的荫蔽下的沃通 (WoSign) 所[i]秘密[/i]收购的 StartCom 旗下的吗?

      删除
  6. 目前有兩個都是基於TrueCrypt開發的開源加密軟件,都是跨平臺的
    分別是VeraCrypt 和 ciphershed
    VeraCrypt 加密格式不兼容TrueCrypt,但迭代次數比它(TrueCrypt)還要多,是否意味着比TrueCrypt還安全呢?
    另一個ciphershed 則打算兼容TrueCrypt,其他的不太清楚

    對這兩個加密軟件沒太大把握,不知安不安全,博主評測下吧

    回复删除
    回复
    1. VeraCrypt由于迭代次数比TrueCrypt还要多, 挂载时会慢很多很多
      (但加/解密则没有影响)
      ciphershed则未有正式推出

      删除
    2. TO v499
      問題是迭代次數多是不是就比TrueCrypt安全呢?

      删除
    3. 此评论已被作者删除。

      删除
    4. TO 6楼的网友
      关于这两款 TrueCrypt 的替代品,俺有听说过,但还没有深入去了解和使用。
      俺目前还在观望。
      TrueCrypt 暂时还没有出现啥严重问题,先不要急于切换。

      删除
    5. TO 6楼 和 2单元
      应该是同一人吧?

      关于迭代次数
      你说的应该是 验证“密码 和 keyfile”过程中的那个迭代次数。
      这玩意儿主要是对抗暴力破解的。

      如果你已经使用了很复杂的密码(口令),并且还配合了 key file,那么以 TrueCrypt 默认的迭代次数,暴力破解也是没戏的。
      反之,如果你【没有】用 key file 并且密码/口令【很简单】。
      那么即使用了更多的迭代次数,依然会有较大的暴力破解的风险。

      所以,“个人的习惯”比“迭代次数”更重要。

      删除
    6. 我就坚持在用TrueCrypt加密, 没发现什么问题, 目前也没有更好的替代品。
      TC作者的声明, 总感觉欲言又止、遮遮掩掩、糊里糊涂的 , 到底是什么漏洞或安全隐患一个字都没提 ...

      我使用的是超过20位的复杂密码, 字母数字符号混合的, 另有两个key file ,用winrar加密压缩保存在U盘上 。
      目前没发现TC有主动联网的动作, 打算就用防火墙严格控制外来连接(原则上只出不进), 使用完TC就立马卸载虚拟加密盘 。

      这样使用应该没什么问题吧!

      删除
    7. 只出不进:
      request 出不了如何进?

      TC作者的声明, 总感觉欲言又止、遮遮掩掩、糊里糊涂的 , 到底是什么漏洞或安全隐患一个字都没提 ...
      若真是有的, 他说出来我们就完蛋了

      删除
    8. 呃... 我兩者混用應該更安全些吧(也就是VeraCrypt+TrueCrypt)!
      只是麻煩了點。
      不過博主自己沒審計過TrueCrypt漏洞/後門嗎?
      以及他推薦過的那些開源軟件(比如個人開發的小狼毫輸入法)自己都沒審計過嗎?

      删除
    9. 呵呵, 我说的“只出不进”是指本机系统和软件可以对外发起连接,但原则上不接受\禁止外部网络对本机发起的任何连接请求 。
      另外, 系统上安装了HIPS类软件, 对系统(包括软件)的所有动作进行监视和控制 , 到目前为止, 并没发现TC有任何异常行为。

      删除
    10. TC倒不至于说搞类似木马的东西。但是你如果不审计代码,能确定里面没有算法方面的弱点或者后门吗?

      删除
    11. 我想問下,現在比特幣還能用嗎?
      我想用比特幣購買國外付費的vpn,
      不知道怎麽才能在保證匿名(不涉及到實名認證的交易)的前提下兌換比特幣呢?
      很快會被封鎖嗎?

      删除
    12. TO mick 和 冒牌的“忠党爱国”
      关于 TC 是否有问题,俺赞同 冒牌的“忠党爱国” 所说。
      因为 TC 之前已经搞过代码审查,而且 TC 用户群很大(其用户中不乏专业的安全人士)。
      所以, TC 不太可能有很明显的后门(诸如你担心的“网络外联”之类)。
      如果真有这类后门,早就被人发现了。

      假设(仅仅是假设)TC 存在后门,那多半也是某种“加密设计层面”的后门。
      这种后门,需要由“具有深厚密码学背景、同时具有深厚编程背景的人”进行仔细审查,才能发现。

      删除
    13. TO Anonymous-think
      俺没有审计过 TrueCrypt 的代码。
      如今,俺连读者来信,都没时间处理。
      哪还有空去审查开源软件的代码。

      如果真要【认真】审查某个软件的代码,并且该软件的代码量不是太小。
      通常都挺花时间的。

      删除
    14. TO 11单元的网友
      先声明:俺对 “比特币兑换” 并不熟悉。
      根据俺对比特币的了解,比特币 在设计上,并【没有】专门强化“匿名性”。
      这里有一篇长文,里面提到——对比特币进行【去匿名化】的技术;也提到某些强化匿名性的方法。
      http://www.8btc.com/trustless-bitcoin-anonymity-here-at-last

      删除
  7. 博主請回復下前一篇博文34樓和51樓4單元的問題

    鏈接: http://program-think.blogspot.com/2014/11/https-ssl-tls-1.html?comment=1415759742262 34樓

    http://program-think.blogspot.com/2014/11/https-ssl-tls-1.html?comment=1416045325977 51樓4單元

    回复删除
    回复
    1. TO 7楼的网友
      周末这两天在集中回复评论,等一下应该就会处理到你说的那两条留言。

      删除
  8. 有时候我觉得不进行密钥交换感觉更妥当。在服务器和客户端部署一个Long Term Key,然后使用的时候,每次连接的对称密钥可以通过计算key = Hash(Long Term Key|| Nonce)得出,也可以用更安全的算法如PBKDF2(Nonce是每次会话产生的一个随机值)。当然这只能用于某些比较特别的应用,对于https之类的没什么用。。

    回复删除
    回复
    1. 不要自己设计加密方案。

      你这里的显然问题是,对于几乎是无限的用户,你如何去部署服务器和你交换密钥?另外密钥的储存呢?
      比如现在我办了一个abc.com,请你来访问,你是喜欢直接用https访问呢,还是要来我这里公司总部登个记再用呢?

      此外,这种长期密码本一旦丢失,过往的数据,如果它们被NSA记录下来,也就都能解密。
      如果使用不对称加密,经过一些设计可以避免这个问题。比如只泄漏一段时间之内的。

      删除
    2. 原理听起来类似于移动平台的Google验证器?

      删除
    3. TO Curtis Wilbur
      你提到的这种方式,类似于本文中介绍的——基于某些“私密的共享信息”
      你所说的“Long Term Key”就相当于“私密的共享信息”

      这种策略,最大的难点是部署。
      面向公网的网站,显然没法用这招。

      删除
    4. TO 冒牌的忠党爱国

      这个方案不是我想出来的,是以前在某个教材的一个习题上看到的,目前的Shadowsocks加密密钥也是通过这种方式产生。
      你说的第二点,其实我在最后有提到,说这种方案对于https不适用,意思就是说无法面向太多的用户。

      你说的最后一点,确实也有其风险之处,不过可以定期更改Long Term Key来降低风险。

      个人认为这种方式比较适合用于翻墙,比如像OpenVPN之类的,现在使用证书认证方式进行连接,即使改了协议为udp,而且不断修改端口,用不了几次仍然被GFW检测出来(密钥交换阶段所有交互流量都是明文,GFW可能发现了某些特征),如果使用上面提到的方式,倒是没有什么问题(当然,前向安全性肯定会大打折扣)。

      删除
    5. 如果不用在http上,那么预享密钥是可以的。但是也需要仔细的设计。
      比如预享的也可以是不对称密钥。现在还没有那么危险。自己实现使用椭圆曲线密码还是能实现很高的安全性的。
      如果一定只要对称加密,这方案也没啥问题。毕竟你可能有更安全的方式,比如ssh登录,去给shadowsocks部署密钥。

      删除
    6. 那怎么解决这个Long Term Key在发给你的途中就被截获的问题呢?

      删除
  9. 敢情android手机翻墙也太容易了,fqrouter一路回车就行,让人心里有点嘛~_~

    回复删除
    回复
    1. TO 9楼的网友
      Android 的翻墙确实比其它手机系统要方便一些(翻墙工具比较丰富)
      fqrouter 只是其中之一
      《[url=http://program-think.blogspot.com/2014/07/gfw-fqrouter.html]“如何翻墙”系列:fqrouter——安卓系统翻墙利器(免ROOT)[/url]》

      删除
  10. 感觉VirtualBox在linux下比vmware稳定
    (不知是否与我没用swap有关系)

    回复删除
    回复
    1. TO v499
      俺倒是觉得这两款 VM 软件的稳定性差不多。

      另,
      感觉在 Linux 下跑多 VM 比 Windows 下跑多 VM,性能要好很多。

      删除
    2. 我用vmware时
      那个甚么vmx很易就crash
      突然想到: 可能是因为我enable了3D, 而我的display card又是被vmware blacklist了的, 是我强行开启....

      另, 同意 Linux 下多 VM性能要好 :)

      删除
    3. TO v499
      或许真的是显卡和 3D 方面的原因。
      俺用 VMware 几乎没碰到 crash

      删除
  11. 第3步
    .....................
    因为 pk1 pk2 都是攻击者自己生成的,所以攻击者自然就可以用 pk1 来解密 k' 得到 k
    然后,攻击者拿到 k 之后,用之前截获的 k1 重新加密,得到 k'',并把 k'' 发送给网站。

    博主,这里是不是有笔误啊,“然后,攻击者拿到 k 之后,用之前截获的 k1 重新加密”,是用之前截获的 k2 重新加密吧。

    回复删除
    回复
    1. TO 11楼的网友
      非常感谢你的仔细阅读并发现本文的笔误 :)
      刚才已经更正。

      另,你这条留言被 Google 误判为垃圾广告,俺刚把它恢复出来

      删除
  12. 翻墙问答﹕谷歌新推出USB二步认证功能


    问:一直以来,谷歌Gmail都是中国黑客偷窃资料的对象。而中国所有电讯公司都是国有企业,不少网民都担心透过手机短信传送确认码的二步认证功能,是否真的保证中国网民的资讯安全。

    而最近谷歌推出了可以绕过电讯网络的二步认证方法,不知这方法是怎样的?李建军能否介绍一下?

    李建军:谷歌在美国新推出的USB二步认证功能,利用FIDO U2F硬件认证匙,只要将你买到的认证匙连结到你的谷歌户口,每次登入Gmail或其他需要二步认证服务的谷歌服务时,插入相关认证匙到USB插口,再按认证匙上的按键一下,就完成整个二步认证程序,完全不用经任何中国国有电讯网络,这有助解决中国当局拦截谷歌认证短信,或突然取消你的手机服务,令你无法收到二步认证确认信息等一连串问题。

    问:那FIDO U2F支援什么作业系统以及硬件平台?因为过往不少听众,使用中国国有银行以U盘形式提供的二步认证服务,都受到十分大的限制?FIDO U2F又会否出现这种情况?

    李建军:FIDO U2F在任何有USB插口的电脑上都能运作,而且主流大部分作业系统,包括Mac、Windows都Linux都没有问题,弹性比中国国有银行那些只能在Windows上执行的U盘大得多。

    只不过,在浏览器上就有限制,暂时只有谷歌自己推出的Chrome浏览器支援FIDO U2F二步认证,而且要Chrome 38版或以上才可以。使用Firefox或Safari的用家,如果想享受由FIDO U2F带来的好处,就可能要下载Chrome浏览器,并透过Chrome浏览器来登入Gmail。

    但由于FIDO U2F是开放源码标准下运作,并不像中国国有银行普遍使用封闭源码方案,因此相信未来其他开放源码的浏览器,包括Firefox,以及与Chrome技术相似的Safari,都会支援FIDO U2F。

    问:FIDO U2F的加密匙会否在中国制造,令保安程度出现问题?

    李建军:现时所有FIDO U2F技术的加密匙,都在法国和美国制造,暂时未见中国制产品,这点可以放心。

    问:那暂时那里可以买到FIDO U2F USB二步认证加密匙?

    李建军:由于暂时在美国和欧洲先推出,因此中国,甚至香港暂时都未有出售相关产品,想用这种二步认证技术的人,可以透过亚马逊在美国或欧洲的网站订购,但需要听众有信用卡,以及只能送到美国或欧洲的地址。这可以委托在美国或欧洲的亲友,或个别愿意承受风险的代购公司代购。

    问:现时FIDO U2F二步认证匙,只支援USB,那对流动电话、平板电脑等用家很不方便,因为这类硬件都不会有USB插口,那未来是否有可能出现支援手机、平板电脑甚至电视机顶盒的FIDO U2F二步认证匙?

    李建军:现时FIDO U2F联盟各成员,包括谷歌在内,正研究能够配合蓝芽以及NFC技术的FIDO U2F硬件匙技术。在未来,只要将FIDO U2F硬件匙以蓝芽连接到手机,甚至像深圳通卡、八达通卡一样,只要将FIDO U2F硬件卡拍到支援NFC的设备上,就可以完成整个二步认证程序。相信未来有蓝芽版和NFC版的FIDO U2F设备后,绝大部分装置都可以支援透过硬件进行二步认证程序,未来二步认证程序对手机短信的依赖会越来越少。

    问:是否意味著手机短信二步认证终有一天会被淘汰?

    李建军:可以这样说,因为手机短信无加密功能,而且成本昂贵。Whatsapp一类应用程式兴起后,人们使用手机短信机会大减。因此,寻求手机短信二步认证的替代方案,可谓大势所趋。 (完)

    回复删除
    回复
    1. TO 12楼的网友
      多谢分享安全方面的文章 :)

      删除
    2. YubiKey 已经支持FIDO U2F了. 并且不限于USB, 还支持 NFC/蓝牙 方式直接生产Token.

      删除
    3. TO 2单元的网友
      多谢补充 :)
      俺希望不久之后也能支持 Firefox,
      也希望这种”二次认证”的硬件能尽早在亚洲地区销售

      删除
    4. TO 2单元的网友
      多谢补充 :)
      俺希望不久之后也能支持 Firefox,
      也希望这种”二次认证”的硬件能尽早在亚洲地区销售

      删除
    5. 但是这是否会带来新的隐患?如果在你家搜出了这个东西那就无法抵赖了。

      删除
    6. TO 5单元的网友
      俺没有看过 FIDO U2F 的源代码或技术文档。
      不过俺猜测:
      如果用 FIDO U2F 进行 Gmail 的两步认证。即使有人拿到这个硬件,并【不能】反向推测出你用的是哪个 Gmail 帐号。

      删除
    7. 本评论注定被吃2014年11月27日 00:20:00

      时间差不多,我都怀疑FIDO U2F被土共偷来“自主”成网络身份证。

      删除
  13. 编随小心呀
    TOR 也不安全了...不知道多重代理可以吗?

    哥伦比亚大学网络安全实验室前研究员、目前在Indraprastha信息技术研究所研究网络匿名和隐私的Sambuddho Chakravarty教授指出(PDF),思科路由器监视网络流量的软件Netflow能被用于识别Tor匿名用户的身份,成功率可以达到81.4%。去匿名化的方法是向Tor出口节点相关联的TCP连接中注入重复的流量模式,随后比较Netflow所产生的流量流动记录的网络计时差异,让Tor用户个体化。在实验室条件下,流量分析攻击的成功率能达到100%,在实际条件下网络噪声和变化会将成功率降至81%.
    http://www.solidot.org/story?sid=41893

    回复删除
    回复
    1. 还没说能实用不呢。有很多先决条件,不要识得风就是雨。

      删除
    2. TO v499
      俺今天也看到 solidot 上的这篇报道了。
      针对 TOR 的流量分析,前两年就有相关的研究成果见诸报端。
      至于如何应对,俺在《[url=http://program-think.blogspot.com/2013/11/tor-faq.html]“如何翻墙”系列:关于 TOR 的常见问题解答[/url]》一文,大致提了一下。

      如果有空,俺会针对“流量分析”这个话题,再专门写一篇“如何防范”的扫盲教程。

      删除
  14. 老大出现了笔误吧?
    "然后,攻击者拿到 k 之后,用之前截获的 k1 重新加密,得到 k'',并把 k'' 发送给网站。"这里"之前截获的 k1 "应该是"之前截获的 k2"哟!

    回复删除
    回复
    1. 确实。看得很仔细啊。

      删除
    2. TO 11楼的网友
      非常感谢你的仔细阅读并发现本文的笔误 :)
      刚才已经更正。

      (11楼 的网友也发现了这个笔误)

      删除
    3. TO v499
      2单元那条,确实是笔误 :(

      删除
  15. https非对称连接是最危险的。https可能还是重点监控目标。特别是在国内用,一个不小心就又多出来个CNNIC的新证书,防不省防。偷鸡不成蚀把米

    回复删除
    回复
    1. 多出来个CNNIC的新证书: 这个用public key pinning 可以解决
      另, 不知道你指的https非对称连接是甚么

      删除
    2. TO 15楼的网友
      你提到的“非对称连接”,是不是原来想说“非对称加密”?

      删除
  16. 现代国家最基本的特征是文明。现代国家文明的基本特征是国民拥有公民身份,只有公民才具有选举权和被选举权。现代文明国家主要由公民组成。占据中国大陆国号为“中华人民共和国”的国家国民目前只有居民身份证,没有公民身份证。占据中国大陆国号为“中华人民共和国”的国家主要由居民组成而非由公民组成。主要由居民组成的国家是一个古代国家,而不是一个现代国家。也就是说,目前占据中国大陆国号为“中华人民共和国”的国家是一个古代国家,而不是一个现代国家。
    具有公民身份是现代国家国民最基本的政治权利,目前国号为“中华人民共和国”的国民全部都没有现代国家国民最基本的政治权利。也就是说,中国大陆“中华人民共和国”国民,不管是国家主席还是普通老百姓,从一出生开始就被剥夺基本政治权利终生。
    也就是说,大陆中国人到目前为止还是一个古代概念而不是一个现代概念,大陆中国人到目前为止还是一个古代国家的国民而不是一个现代国家的国民,大陆中国人到目前为止还在被一个古代国家剥夺基本政治权利终生。

    回复删除
    回复
    1. TO 偶尔感冒
      多谢分享你的观点——通过揭示基本的政治概念,曝光天朝的奇葩之处。

      在天朝,大部分民众不光缺乏“公民”的名分,更糟糕的是缺乏相应的头脑——没有“公民意识”,只有“臣民意识”
      所以俺一直强调要普及“政治素质”

      删除
    2. 本來還想寫點啥的,想想又不敢寫(有些話感覺不適合在這公開討論,不是因爲怕跨省),還是發Email跟博主交流吧!

      删除
    3. TO 2单元的网友
      如果给俺发邮件,你要有思想准备哦。
      有可能要超过1个月(或更久),才会给你回信。
      因为俺平时收到的读者来信太多,都来不及处理了 :(

      删除
  17. http://e2546.g.akamaiedge.net/f/1/1/1/dci.download.akamai.com/35985/159415/1/c/?u=/chinese/2014/11/%E5%8A%A8%E5%90%91%E6%9D%82%E5%BF%97%EF%BD%9C%E4%B9%A0%E8%BF%91%E5%B9%B3%E7%9A%84%E6%82%B2%E5%89%A7%E6%89%A7%E6%94%BF%EF%BC%9F/
    动向杂志|习近平的悲剧执政?
    http://a859.g4.akamai.net/f/1/1/1/dci.download.akamai.com/35985/159415/1/c/?u=/chinese/2014/11/%E4%B8%9C%E7%BD%91%EF%BD%9C%E9%9D%9E%E9%9F%A9%EF%BC%9A%E8%BE%BD%E5%AE%81%E6%97%A5%E6%8A%A5%E6%89%B9%E8%AF%84%E9%AB%98%E6%A0%A1%E4%B8%8D%E6%98%AF%E5%AD%A4%E7%AB%8B%E4%BA%8B%E4%BB%B6/
    东网|非韩:辽宁日报批评高校不是孤立事件
    http://e3191.dscc.akamaiedge.net/f/1/1/1/dci.download.akamai.com/35985/159415/1/p/?u=/article/260
    网络文革:警惕文革的文革制造者
    http://e3191.dscc.akamaiedge.net/f/1/1/1/dci.download.akamai.com/35985/159415/1/p/?u=/article/259
    “持证上网”时代即将来临?

    http://cn.nytimes.com/china/20141113/c13tiger/
    老虎脖子上的铃铛,外媒还得自己解
    http://cn.nytimes.com/opinion/20141113/c13editorial/
    回应习近平
    http://cn.nytimes.com/china/20141113/c13visas/
    习近平点破负面报道与记者拒签联系

    回复删除
    回复
    1. TO 17楼的网友
      多谢分享近期的时政点评文章 :)

      删除
  18. http://allinfa.com/big-intelligence-top-secret-project.html
    揭秘公安部“大情报”绝密工程: 建设10年 监控13亿人
    ——防民之术的最新进展
    https://www.indiegogo.com/projects/lantern-one-device-free-data-from-space-forever
    Lantern: One Device, Free Data From Space Forever
    ——卫星上网的最新进展

    回复删除
    回复
    1. TO 18楼的网友
      关于这个所谓的“大情报”工程,其实就是金盾工程。
      好多年之前就有了,而且也算不上是“绝密”。

      删除
  19. gossh安全吗,怎么网上找不到介绍

    回复删除
    回复
    1. TO 19楼的网友
      gossh 的安全性,应该类似于”墙外的VPN“。
      如果你对安全性的要求比较高,可以采用 SSH+TOR 的方式,构造双重代理
      相关教程参见《[url=http://program-think.blogspot.com/2010/04/howto-cover-your-tracks-0.html]如何隐藏你的踪迹,避免跨省追捕[/url]》

      删除
  20. 本评论注定被吃2014年11月18日 20:01:00

    来自自信部门
    屏蔽CDN可能是防火长城的大规模杀伤性武器,因为这会附带影响大量使用该CDN服务的网站。在Google被屏蔽之后,使用托管在Google上的字体或脚本的网站出现了加载或访问问题,如使用reCAPTCHA防机器人的网站不能正常显示验证码。现在,防火长城DNS投毒了CDN服务商EdgeCast的域名*edgecastcdn.net,连带着数千家网站被屏蔽了,其中包括了非常无辜的开源内容管理系统drupal.org,索尼移动,大西洋月刊,火狐插件(addons.cdn.mozilla.net托管在 EdgeCast上),Gravatar、speedtest.net,等等。EdgeCast官方博客证实它被防火长城加入到了过滤名单,原因未知。

    回复删除
    回复
    1. 準備拔網線的前兆吧(只允許政府高層上網)?

      删除
    2. 本评论注定被吃2014年11月18日 23:43:00

      [url=https://zh.greatfire.org/blog/2014/nov/china-just-blocked-thousands-websites][b]数千个网站在中国遭“一锅端”[/b]
      percy 星期二, 11月 18, 2014 发布[/url]

      Edgecastcdn.net在中国遭到域名服务器缓存污染攻击,导致其下的所有子域名在中国被封。EdgeCast是全球最大的内容分发网络(CDN),为中国成千上万的网站和app提供云服务。

      网络监测组织GreatFire使用“依附的自由”方式为网站解封,其假设便是,中国不会封锁通往全球内容发布网络的连接,因为当局很清楚中国融入全球互联网的价值。但该组织此次宣称,中国当局正试图将中国从全球互联网中孤立出来。

      在过去数日内, “依附的自由”技术带来了许多“连带破坏”。GreatFire组织收到一些小网站发来的邮件,这些网站弄不清,为何自己网站的内容并不敏感,却遭到防火墙的封锁。
      [b]发生了什么[/b]?

      据GreatFire称,他们于2014年11月13日监测到对EdgeCast的首个污染攻击。EdgeCast于2014年11月14日在其网站上告示,其服务在中国遭到干扰。并于17日发表相关博客称:

      从我们的CDN、业界合作伙伴、和我们的用户处得知,愈来愈多的网站、CDNs和网络遭到中国防火墙过滤和封锁。本周,我们目睹了过滤升级,越来越多的网站遭到影响,甚至我们的一个服务器遭到部分封锁······当局没有提供任何理由。

      [img]https://lh6.googleusercontent.com/mMUe1FFOD-GA4la8-0tUxpqS-bbmtDFKbh-DRWTsEm-T1SLQ7ch0MuVadMzPOt-nf5ksJ2GrMebDrQvJEDOWgQ6Guv80Q8O2jRAM-NQ3jOKV1u0PrZFadCJaOf0cVwyQ0A[/img]

      该公司称,已推出相应政策和措施,协助用户应付中国此次的封锁,且表示“这是一直持续的问题”。

      受影响的网站(皆为EdgeCast用户)包括:

      索尼移动 的全球网站和中国网站均遭到封锁。

      《大西洋月刊》The Atlantic

      Drupal (drupal.org)的项目网站被封。全球许多网站都使用Drupal作为后来框架。而中国使用 Drupal的网站管理员在升级Drupal或安装插件时,将面临干扰。

      Firefox浏览器的插件:Firefox的 addons.cdn.mozilla.net使用EdgeCast的服务器,该浏览器的中国用户将无法安装任何插件。

      Gravatar 被许多网站用来显示用户图片。这些图片都使用EdgeCast的服务器,任何使用 Gravatar的中国网站都将无法正常显示用户图片。中国用户上这些网站后,将遇到下图中的情况。
      [img]https://lh6.googleusercontent.com/ainvpwHDEJyUfbWLQXpAxNEDESsyn8lVZqY2ukWDGRMdeD7kSn3jKjrBD9Vqo1dh9Z1A-ldhqbLYbslTkjfUjVeSoaOGnVofxMJfY0Q-mjhB8WXvYvrMzSqfqjufj3mepQ[/img]
      其他被封的网站包括speedtest.net 和 deviantart.com。由于不同网站的不同元素(如图片)可能都依赖于EdgeCast,因此无法确切告知哪些网站遭到影响。EdgeCast 用户列表 上的所有网站可能都受影响。以下是一些EdgeCast用户的截图。

      [img]https://lh6.googleusercontent.com/omV3iIfhU_sksS-jla7ySAAOQMapC9A5xjmrlnzUaj7e7TtBqAJWAyWkwVOO9XKuZNO8wSN8EB2ZDh_gFdT7r-8hcH2M1g-Iob6SCSBM_mo4w0a8SoWctaU87rnEvDvhuQ[/img]

      [b]原因[/b]

      中国防火墙试图封锁GreatFire所提供的所有“依附的自由镜像网站”(包括泡泡网),这些网站都被放在全球云服务器上。防火墙无法区分到云服务器上的交通,要封锁这些镜像网站,就必须封锁所有到该内容发布网络的通道。GreatFire的做法,迫使中国当局选择,是要让用户通往不受审查的网站,还是将全球的CDNs一锅端,一锅端的话将给中国经济带来重大的成本。

      当局选择封锁EdgeCast的所有服务,成千上万个网站因此遭殃。许多企业将受到影响,很可能造成重大的经济损失。

      EdgeCast近期被Verizon购买,而Verizon的董事会中包括许多在中国有巨额投资的公司高级负责人,包括皇家荷兰壳牌、宝洁公司和迪尔公司。

      如果当局起初没有预料到封锁EdgeCast所造成的伤害,许多使用EdgeCast的中国公司也现在很可能已经提醒当局了。中国本周正在举行世界互联网大会,封锁EdgeCast很可能会成为热门话题。GreatFire呼吁中国政府立即解封EdgeCast。
      [b]Update[/b]

      EdgeCast removed the status [b]update[/b] on its website, but have published a blog post about their current problems in China:

      We have been hearing from our CDN and Monitoring partners throughout the industry and our own customers that more sites, CDNs and networks are being filtered or blocked by the Great Firewall of China. This week we’ve seen the filtering escalate with an increasing number of popular web properties impacted and even one of our many domains being partially blocked… with no rhyme or reason as to why.

      At Verizon EdgeCast we have put policies in place to help our customers mitigate the effects of this most recent filtering but expect this to be an ongoing issue for our customers seeking to reach Chinese users (users in China). For any customers who are seeing their delivery impacted, please log in to your EdgeCast portal. Here you will find instructions on your portal home page on how to best mitigate filtering or blocking.

      For those of our customers who are frustrated by this, we share your frustration, as does the whole content delivery and hosting industry. Rest assured that we stay committed to work with our global ISP partners and do our best to mitigate the effects of these filtering policies to ensure a clear path to your users and customers in China.

      删除
    3. TO 本评论注定被吃
      你在 2单元 的长篇留言被 Google 误判为垃圾广告,刚才俺把这条留言恢复出来了。

      多谢分享 GFW 的新动态 :)

      删除
    4. TO 1单元的网友
      在如今的天朝,经济领域已经非常依赖于互联网。“物理断网”不太可能发生——除非出现严重的政治危机。

      删除
    5. 长城或者封IP、或者封域名,封IP是误杀这个服务器上的所有站点,后果是最严重的,一个IP上往往有几百个网站的

      删除
  21. 请教各位能人,哪个付费的外国VPN安全和效率比较可靠滴? 俺要回国,不懂翻墙的,(听说付费的VPN有二次模糊加密),俺是否可以外国支付先买个号回国用?

    俺只要能用谷歌搜索 , 百度只要是外文的学术的性搜索一概没法用, 要老命啊!有些地方外国话的一概被墙,连个外国天气预报不给看, 不知哪根神经错乱.要老命啊!!!(俺小时听不懂一同学的古怪方言很森气, 不知大篱笆是否看不懂德意法文就森气一定要墙).

    向所有在这种环境下国内做学术研究工作的致敬!

    回复删除
    回复
    1. Google https://github.com/greatfire/wiki
      而VPN则要查在天朝里被墙了没有

      删除
    2. 用google搜索“anonymous vpn“有些支持比特幣付款的vpn提供商(尤其是支持匿名BT下載的),應該比較可靠吧!

      免費的如vpngate、賽風3或者用google以“free vpn“爲關鍵字搜索
      也能找到些未被和諧比較小衆的國外免費vpn

      删除
    3. TO 21楼的网友
      俺从来不用【付费】的VPN。
      因为俺比较重视”隐匿性“,而”付费“的环节容易导致个人信息的暴露。
      所以这个问题俺没法回答。抱歉 :(

      TO 1单元 和 2单元
      多谢替俺回答问题 :)

      删除
    4. TO 2单元的网友
      提醒一下:
      ”比特币支付“,匿名性可能没有你想象的那么好。
      参见俺在”3楼 22单元“的留言

      删除
  22. 您能帮忙看看赛风是什么原因通过sc32及类似工具,不能调用远程桌面的原因吗?能解决最好,因为tor太慢了。虽然tor很安全

    回复删除
    回复
    1. 雙虛擬機搭配多重代理搞定端口轉發不就行了麼?
      調用遠程桌面幹嘛呢?

      删除
    2. TO 22楼的网友
      貌似你之前来问过类似的问题。

      建议你尝试一下 TOR 的 meek 插件,可以让 TOR 独立联网。
      教程参见《[url=http://program-think.blogspot.com/2014/10/gfw-tor-meek.html]“如何翻墙”系列:TOR 已复活——meek 流量混淆插件的安装、优化、原理[/url]》
      关于速度
      俺自己的环境中,meek 不算太快。
      但是某些读者反馈说他们的环境很快。

      删除
    3. 俺连不上meek,所以才问,因为tor慢所以才用赛风

      删除
    4. TO 3单元的网友
      在前面博文的评论中,俺回答过。
      根据你的几次试验结果(同样环境,TOR 连通,赛风连不通),俺猜测:有可能是赛风对 SOCKS 的代理的实现有bug。

      删除
    5. 难道说此题无解?是不是赛风对对某些公网端口作了限制呢?为什么只有socks协议可以代理远程桌面,http不行呢?

      删除
  23. [IMG]http://i.imgur.com/YEdEJIW.png[/IMG]
    这两句话好精辟!

    回复删除
  24. [img]http://i.imgur.com/YEdEJIW.png[/img]
    "[img]"标签竟然不支持大写。。。

    回复删除
    回复
    1. TO 枫之落叶
      多谢分享网络评论 :)

      关于本博客的 BBCode 语法
      目前采用的是大小写敏感的方式。

      删除
  25. 跟博主交流有共鳴(在閱讀作者的作品中思考也是種交流吧,但投其所好是無法體會到共鳴滴),
    有些啓示意義,好像強迫開啓讀者的批判性思維似的。

    跟博主私信交流應該比在這稍微遜色的“公共場所”留言更有趣,只是時間久了點
    耐心等吧...

    回复删除
    回复
    1. TO 25楼的网友
      多谢捧场 :)

      如果你给俺发过邮件,可能一个月之后才会收到回复。
      因为读者来信太多,处理不过来 :(

      删除
  26. 海南又發生大規模示威了(警車被敲打,也是與污染食用水有關),警察施放催淚彈鎮壓

    http://hk.apple.nextmedia.com/international/art/20141119/18940076

    回复删除
    回复
    1. TO 26楼的网友
      多谢分享天朝的“不和谐新闻”

      删除
  27. 请问博主,对于在墙外的人群,没有翻墙的需求,但是要求隐匿性以及对暗网的访问能力,您所倡导的双代理/双虚拟机还有必要吗?如果要改动应该怎么做呢?尤其是虚拟机,占用资源比较大,别说双重了,对于设备不是那么好的人来说一个虚拟机都卡。

    回复删除
    回复
    1. 雙虛擬機搭配多重代理對牆內牆外都是通用的,舉一反三嘛!(否則也不會有那個whonix系統了,技術不分國界,原理通用)
      設備老舊/不好用那就更新吧,“磨刀不誤砍柴工”啊!

      删除
    2. 補充一下:
      把自己想象成“斯諾登”或牆內高危人群需求就會變得很迫切了(跟“喬布斯把每一天都當成生命的最後一天”一樣原理)
      當需求很迫切時就會促使自己去改變,不就很有必要了嗎:)

      删除
    3. TO 27楼的网友
      如果你对”隐匿性“有要求,那么”虚拟机“和”双重代理“依然是必要的——哪怕你在墙外。
      基于 TOR 的”双重代理“,非常有利于隐匿你的公网 IP
      ”虚拟机“有利于进行网络隔离,避免某些本地的软件绕过代理,独自联网(这种情况会暴露公网 IP)

      如果你的硬件不够好,可以不用”双虚拟机“,改用”单虚拟机“
      具体教程参见《[url=http://program-think.blogspot.com/2010/04/howto-cover-your-tracks-0.html]如何隐藏你的踪迹,避免跨省追捕[/url]》

      删除
  28. 博主,现在的pptp vpn会否已被共匪破解了呢?
    https://twitter.com/Vela1680/status/532068496788574208
    https://plus.google.com/u/0/109790703964908675921/posts/AXgoJutf5sz
    vpn+https还是安全的吧

    回复删除
    回复
    1. TO 28楼的网友
      看了你分享的 Twitter 链接,俺倾向于赞同 @balepapapa 的观点。
      有可能那个用户是自己误操作或配置有误。

      暴力破解,针对某个特定 IP 的流量,或许还可行。
      但如果是针对 ISP 接入公网的流量,或者是国际出口的流量,不太可能。

      删除
  29. 博主,pptp vpn会否已被共匪破解
    https://twitter.com/Vela1680/status/532068496788574208
    https://plus.google.com/u/0/109790703964908675921/posts/AXgoJutf5sz
    vpn+https应该还是安全的吧?

    回复删除
    回复
    1. vpn(也可以vpn嵌套)+tor,這才算安全!
      國內vpn會遭到脅迫不要用已是老調重談了,不用說明了吧

      删除
    2. https://plus.google.com/u/0/109790703964908675921/posts/AXgoJutf5sz
      有趣的是這個帖子把本博客鏈接和一些讀者留言都包含進去了,還用問嗎?

      删除
    3. TO 29楼的网友
      你跟 28楼 是同一人吧?
      俺已经回复 28楼 了。

      TO 1单元 和 2单元
      多谢两位替俺回答 :)
      俺也认为”国内的 VPN“不可靠。
      另外,俺已经强调了很多次”双重代理的重要性“

      删除
  30. 最新那篇博文無法加載評論了,留言區越來越爛

    回复删除
    回复
    1. TO 30楼的网友
      如果评论区无法正常加载。多刷新几次。
      如果多刷新几次也不行,可以找另外一篇不同的博文(评论数超过200条的)刷新一下,然后再来刷新这篇。
      或许就可以了。

      因为加载评论的核心代码,是 Blogspot 平台的,而不是俺写的。
      上次改版的时间仓促,暂时还没有把这部分代码替换成俺自己写的。
      等到下一个长假(比如春节),俺再来干这事儿。

      删除
  31. 本评论注定被吃2014年11月25日 09:57:00

    V2EX › 分享发现
    百度浏览器的“海外加速”很可能是个有意进行中间人攻击的蜜罐
    http://www.v2ex.com/t/148547

    访问Google等网站时百度浏览器会自动启动baidubrowser_proxy.exe 然后将所有流量重定向到本地的proxy端口 proxy的连接目标在我这里是111.206.37.99 一个北京联通IP
    到这里都还没什么问题,而且用https google时那个proxy也会与那个IP正常建立TLS连接 非常像一个无害的代理
    但抓包后发现从百度的proxy服务器返回的TLS Server Hello信息里证书并不是Google G2而是一个百度的自签发 在wireshark里把字节流导出后得到这么一个证书文件 上传到我个人博客了各位自己看吧。
    http://toby.so/wp-content/uploads/2014/11/BaiduProxyMITM.zip

    当然,百度浏览器本身肯定不会给显示证书的
    [img]http://i.imgur.com/mdoxlGb.jpg[/img]
    具体的信息我再确认整理下一会发,现在可以知道的是这个“海外加速”把所有数据发往北京联通服务器 且可能是个有意对加密连接进行中间人攻击以嗅探内容的蜜罐

    回复删除
    回复
    1. 本评论注定被吃2014年11月25日 10:00:00

      百度浏览器我是坚决不用的,就是给各位想尝试的提个醒。

      删除
    2. 360瀏覽器提供翻牆了(護理給雞拜年啊),誰敢用!

      http://www.chinagfw.org/2014/11/360.html

      删除
    3. 本评论注定被吃2014年11月25日 10:57:00

      回上面,我转的百度浏览器蜜罐证据被吃了。这个30楼其实是我转后留言。

      删除
    4. TO 本评论注定被吃
      你在 31楼的留言确实被 Google 误判了。昨天俺已经把这条留言恢复出来。

      不论是 百度 还是 360,近期都在自家浏览器中整合了翻墙。

      对于关注安全性的网友,千万不要用这种翻墙方式。
      搞不好里面有朝廷走狗下的套,专门收集你访问了哪些不和谐的网站。

      删除
  32. 有什么办法可以防止 恢复软件 恢复直接删除(ps:没有用ERASET或者其他同类型软件)的文件,用了好多次ERASET删除未使用的空间都不能清除掉D盘以前直接删除的文件,用恢复软件还是可以恢复的。E盘(NTFS)无关紧要,擦除成功过,恢复软件不能恢复E盘的直接删除的文件。C盘是系统盘,不能直接擦除。D盘(FAT32)有系统和驱动的备份,不敢轻易格式化所以只能祈求软件能帮忙,系统装有TCL智能盾(系统备份软件)且该软件在D盘部署了一些程序。不知道是不是这个软件还是FAT32的问题,一直使用ERASER擦出未使用的空间都是可以用 恢复软件 恢复直接删除的文件。
    我的D盘可以恢复出像tor,轮子,翻墙软件网站的源文件:)我也是推广翻墙软件的一员:),枫叶香蕉作者被抓后更值得保护电脑的数据了。
    有什么办法可以防止恢复软件恢复直接删除的文件?

    回复删除
    回复
    1. 彻底粉毁硬盘、U盘上的文件用“WYWZ控制台”这个软件,可以把曾经已删除的文件粉碎的干干净净,数据恢复软件连文件名也恢复不出来!“WYWZ控制台”可以把磁盘擦除得像新买时没存放过任何数据一样。在“自设擦除”里有擦除未使用的空间的功能,可以保留现有的文件,擦除已被删除的文件。经常擦除敏感的文件是良好的习惯,突遇查水表就可泰然应对!(注:WYWZ设置的擦除标准为默认的“美国国防部标准方法 ---覆盖3次”,我用多款数据恢复软件测试,均未恢复出任何数据!)

      删除
  33. 建议用“WYWZ控制台”把所有软件运行痕迹也擦除一下。浏览器的历史纪录只简单的删除是没用的,公安的取证软件可以轻松恢复浏览纪录的,下面是目前公安正普遍使用的取证软件“取证精灵”,注意,取证精灵这款软件有病毒,运行了系统就不正常了,所以测试需谨慎!
    http://xiaolan.me/quzhengjingling.html
    网盘:https://onedrive.live.com/redir?resid=2A24B8A135949B48%21107

    回复删除
  34. 大神,这个系列的第三篇文章捏?

    回复删除
  35. 咋没有后续了?

    回复删除
  36. 写得真好, 你在用我们已知的知识来解释未知的知识~ 很喜欢你的文章.

    回复删除
  37. 能否伪造CA证书,或者篡改浏览器的根证书(使得能够匹配错误的CA证书)?

    回复删除
  38. 我还在等着这系列的下一篇文章,何时更啊?博主加油

    回复删除
  39. 感谢博主,期待下一篇文章的出现.已经过了快2年了.....

    回复删除
  40. 方案3第一步错了,购买的数字证书不包括私钥的,自己的公钥私钥是自己本地生产的,然后把公钥加些其他信息生产个csr,csr里没有私钥,只有公钥,然后把这个带公钥的csr提交给ca,ca用自己的私钥做签名,发回给自己,然后把这个部署到服务器上,私钥在任何情况下是不需要给别人,包括ca也得不到你的私钥

    回复删除
  41. 看了你的文章,简洁明了,深入浅出,谢谢。但有一个问题,一直不知道该如何处理,就如GFW对TLS加密连接重置问题:
    在连接握手时,因为身份认证证书信息(即服务器的公钥)是明文传输的,防火长城会阻断特定证书的加密连接,方法和无状态TCP连接重置一样,都是先发现匹配的黑名单证书,之后通过伪装成对方向连接两端的计算机发送RST数据包(RESET)干扰两者间正常的TCP连接,进而打断与特定IP地址之间的TLS加密连接(HTTPS的443端口)握手,或者干脆直接将握手的数据包丢弃导致握手失败,从而导致TLS连接失败

    请问,这有什么方法可以克服吗?谢谢

    回复删除