2014年4月11日

对 OpenSSL 高危漏洞 Heartbleed 的感慨、分析和建议

  4月7日曝光的 Heartbleed 漏洞(编号CVE-2014-0160)已经在相关的 IT 领域(尤其是信息安全领域)造成很大的风波。在安全圈混了十多年,不写点啥有些说不过去。所以今天就这个话题,谈谈俺个人的观点,并给普通用户、程序员、开源社区、安全从业人员 分别提点建议。

不见图 请翻墙


★关于 Heartbleed 漏洞


  这个 Heartbleed,直译成中文就是“心脏出血”。听上去挺吓人滴,现实中也确实挺吓人滴。简而言之,这个漏洞足以载入史册。这几天,大伙儿正在经历信息安全历史上的一个重要时刻。或许你应该觉得荣幸 :)
  关于这个漏洞的描述,请看中文维基百科的“这里”,俺就不浪费口水了。


★先发点感慨


  先发一通抱怨。不喜欢听俺抱怨的,请直接略过。

◇安全行业的耻辱


  对整个安全行业而言,这是巨大的耻辱。
  OpenSSL 是安全行业内应用非常广泛的开源加密库。一个用来保护安全的软件包,本身居然出现如此严重的漏洞(导致内存信息泄漏),实在太讽刺了。
  耻辱的还不光是 OpenSSL——就在一个月之前,GnuTLS 同样出现过高危漏洞(编号 CVE-2014-0092)。这么短的时间之内,涉及到加密的两个最常用的基础库接连爆出高危漏洞,俺不禁要问:整个安全行业的面子要往哪儿搁?

◇开源社区的耻辱


  对整个开源社区而言,这是巨大的耻辱。
  OpenSSL 作为非常知名的开源项目之一,这么严重的漏洞居然两年后才曝光(2012年3月的稳定版就已经包含此漏洞)。难道关键模块的代码变更之后不进行【Code Review】?亦或是 Code Review 只是走过场?


★对该漏洞的风险评估


  该漏洞曝光前后,风险是不同滴。以下俺分别介绍。
  下面会涉及两个术语——“未公开漏洞”和“零日漏洞”——两者的区别请看俺之前的博文

◇漏洞曝光【之前】——作为“未公开漏洞”


  目前已经有报道指出,在4月7日之前,这个漏洞就已经被骇客利用(报道在“这里”)。另外,圈内也有小道消息流传,说某些攻击者早已拿到此漏洞并加以利用。
  在这个阶段,知道漏洞的人很少。这时候,该漏洞属于“宝贵资源”,掌握它的人只会拿来攻击“高价值目标”。所以,如果你只是一个普通网友,或者只是一个小型网站,通常不用担心这个阶段的风险。

◇漏洞曝光【之后】——作为“零日漏洞”


  4月7日那天,OpenSSL 发布了公告。发现漏洞的 CloudFlare 公司也发布了公告。于是这个漏洞瞬间传遍全球。几小时之内,大量的攻击工具应运而生(这个漏洞太容易利用了)。然后大量的“脚本小子”(洋文叫“script kiddie”)就拿着这些别人写好的工具,对大量的网站进行扫描。
  由于时差的关系,以及某些大公司的官僚风气,很多网站来不及在第一时间升级 OpenSSL 这个软件包(这就是所谓的“零日风险”)。估计某些效率低下的公司,甚至到今天都还没升级。
  在这个阶段,对于普通网友
假设你登录过某个网站
假设该网站没有及时升级 OpenSSL
假设该网站存储的是【明文密码】 或者 该网站只在【服务端】加密/Hash密码
假设在你登录期间正好有人利用该漏洞进行信息收集
如果上述几个条件【同时】成立,那么你的密码【有一定的概率】可能被攻击者收集到。


★对该漏洞的技术分析


  (本节聊的是该漏洞在技术层面的细节。对 C 语言了解不多的同学,请自行略过,以免浪费时间)
  这个漏洞从本质上讲,就是“缓冲区溢出(buffer overflow)”。几乎所有这类漏洞的根源,都是由于程序员的疏忽——对缓冲区涉及的相关“长度”没有仔细检查。
  已经有老外写了详细的 Heartbleed 漏洞分析文档(洋文在“这里”)。对于懒得看长篇的同学,俺把精华摘录如下:
  问题出在 OpenSSL 中的 ssl/d1_both.c 文件中的 dtls1_process_heartbeat 函数(看名称就知道该函数是干啥滴)。相关代码有如下(俺补了中文注释)
int dtls1_process_heartbeat(SSL *s)
{
    unsigned char *p = &s->s3->rrec.data[0], *pl;  // p 指向对端发来的心跳数据包
    unsigned short hbtype;
    unsigned int payload;
    unsigned int padding = 16; /* Use minimum padding */
    ......
    hbtype = *p++;  // 心跳数据包的第0个字节,表示心跳包的类型
    n2s(p, payload);  // 后面2字节是长度。n2s 这个宏把这2字节取出为整型,然后指针移2字节
    pl = p;  // 此时 p 指向第3个字节——也就是对端提供的心跳包载荷
    ......
    unsigned char *buffer, *bp;
    int r;
    buffer = OPENSSL_malloc(1 + 2 + payload + padding);  // 多出的3字节用于存放类型和长度
    bp = buffer;
    ......
    *bp++ = TLS1_HB_RESPONSE;  // 填充类型
    s2n(payload, bp);  // 填充长度
    memcpy(bp, pl, payload);  // 填充回应包的载荷【亮点在这里】

  如果对端发来的心跳包有猫腻——包长度跟实际载荷不匹配,那么在发送回应包的时候,那句 memcpy 语句就会把心跳包之后的内存区块也一起 copy 进去,然后发给对端。内存信息就泄露了。
  搞清楚问题的根源之后,补丁其实很简单——只需加入2个判断语句(寥寥4行代码)。
if (1 + 2 + 16 > s->s3->rrec.length)
    return 0;  // 忽略长度为 0 的心跳包
hbtype = *p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
    return 0;  // 忽略长度与载荷不匹配的心跳包
pl = p;

★给普通用户的建议


  前面的“风险评估”已经分析了——对于普通网友而言,你的风险主要在于“漏洞曝光之后那1-2天”(也就是“0day”导致的风险)。
  从4月7日开始的这几天(尤其是4月8日和4月9日),如果你曾经登录过某个重要的帐号,为了以防万一,改一下密码。国内的很多大网站(包括:电子邮件、电子商务、网银、社交网络、等等)都被发现有 Heartbleed 漏洞。
  不过值得庆幸的是,Google 应该没事。根据 OpenSSL 官方的公告(链接在“这里”),漏洞的发现者之一 Neel Mehta 是 Google 的人。所以,俺非常确信,Google 的服务器肯定在4月7日之前就解决此问题了。


★给程序员/架构师的建议


◇“多进程”在安全方面的优点


  刚开博的头一个季度,俺就发过一篇帖子《架构设计:进程还是线程?是一个问题!》,其中提到了多进程的若干优点。今天再来老调重弹,说说“多进程”在安全方面的优点。
  针对“缓冲区溢出”
  绝大多数的“缓冲区溢出攻击”,都只对当前进程有效。如果你的系统切分成若干个进程,一旦不幸碰上这类攻击,顶多只有一个进程出问题——不至于死得太难看。
  不少程序员存在一个误解:以为只有 C/C++ 才会存在缓冲区溢出。其实不然。像 Java/Python 之类的,虽然没有原生的指针,虽然语言的虚拟机/解释器本身对缓冲区越界有严格的检查。但是不要忘了:这些语言的虚拟机/解释器本身也是用 C/C++ 来编写的。说不定虚拟机自己就有问题。
  针对“信息泄露”
  这次的“Heartbleed漏洞”,从技术上讲属于“缓冲区溢出”类型,从逻辑讲属于“信息泄漏”类型。
  如果整个系统切分成很多轻量级的进程,每个进程包含的内存信息自然就少了。一旦出现“信息泄漏”的漏洞,损失会小很多。
  针对“拒绝服务”
  多进程除了可以降低上述两类的受伤程度,还可以降低“拒绝服务攻击”导致的受伤程度。
  比如某些漏洞通过让“进程崩溃”来起到“拒绝服务”的效果。如果系统的架构是多进程的,并且相关进程具有一定的自我恢复机制,那么就可以降低这类攻击造成的伤害程度。

◇关于密码的“客户端加密/散列”


  如今比较成熟的网站,应该不会采用“明文”的方式存储用户密码了。很多程序员/架构师都明白,要把用户密码进行散列(Hash)之后再存储。但是这里面有一个细节,很多人忽略了。那就是:“服务端散列”vs“客户端散列”?

  “服务端散列”和“客户端散列”的差异
  所谓的“服务端散列”就是:用户输入密码之后,以明文的方式传送到服务端,然后在服务端进行散列,散列的结果保存到数据库。
  所谓的“客户端散列”就是:用户输入密码之后,现在浏览器这端用 JavaScript 计算散列值,然后把算好的散列值传送到服务端,再保存到数据库。

  HTTPS 可能出现的问题
  到目前为止,大多数网站(包括很多大型网站)还是采用服务端散列。其实捏,“客户端散列”比“服务器散列”的安全性更好。为啥捏?
  对于成熟的大型网站,虽然用户登录过程都是基于加密 HTTPS 传输。但是 HTTPS 不是绝对安全的。俺相信 HTTPS 协议本身的设计是很完备的,但是“协议没问题”不等于“整个HTTPS传输没问题”。整个 HTTPS 传输,可能出问题的环节如下:
  1. 软件可能出问题
  比如这次的 Heartbleed 漏洞,就属于典型的“基础软件库出问题”
  2. 中间人攻击(比如证书出问题)
  因为 HTTPS 的加密需要依赖于证书体系。如果证书体系出问题就没戏了。
  说两种常见的可能性。
可能性之一:某个 CA 的根证书私钥被盗,那么盗用者就可以随意伪造CA证书。真实的案例是 2011年 DigiNotar 被入侵。
可能性之二:某个 CA 自己就不检点。最贴切的例子非 CNNIC 莫属。这方面的介绍请参见俺4年前的博文《CNNIC 干过的那些破事儿》、《CNNIC 证书的危害及各种清除方法

  “客户端散列”的优点
  看完上述介绍,你应该明白,这几个环节出问题,都有可能让攻击者收集到传输过程中的【明文】密码。如果密码已经在客户端进行散列,那么风险就降低很多(但不是完全降为零,后面会提到)。
  要采用“客户端散列”,有经验的开发人员会对密码进行【撒盐】的散列处理,并且精心选择合适的散列算法(速度足够慢)。如此一来,即使攻击者拿到散列结果,也非常非常难逆向推导出原始的密码。

  “客户端散列”的局限性
  (看到几条读者留言,补充了本小节)
  1、“客户端加密/散列”并不能保证绝对的安全(“绝对安全”是不存在滴)。采用“客户端加密/散列”的前提是——页面的JS代码一定采用可信任的方式传输(HTTPS传输)而不能采用明文的 HTTP 传输。因为 HTTP 传输过程,传输内容是可以被篡改的。如果采用 HTTP 明文传输,万一攻击者篡改了客户端的 JS 脚本,还是会导致密码泄漏。
  2、HTTPS 通道出现的安全漏洞,大致可以分为两类:一类是攻击者可以窥探到传输内容,但无法修改传输内容(比如这次的 Heartbleed 漏洞属于此类);还有一类是攻击者可以篡改内容(比如像 CNNIC 这类流氓 CA 就有条件做到这点)。对于前者,骇客无法突破“客户端加密”的防护;对于后者,骇客可以突破。


★给有志于成为黑客的同学的建议


  先声明:“黑客”与“骇客”是【完全不同】的两类人。俺之前发过一篇《每周转载:关于黑客文化和黑客精神》,或许有助于你了解两者的差异。
  俺敢跟任何人打赌,OpenSSL 和 GnuTLS 的代码中,类似的低级错误还有好多。而且 GnuTLS 可能比 OpenSSL 还多。有志于成为黑客的同学,可以考虑去分析这俩的代码,找出其中的漏洞。
  通过上面那段代码分析,你应该会意识到:这个漏洞本身并没有涉及到多么高深的 C 语法或技巧。那么,发现该漏洞的难点在哪里捏?俺觉得难在:
1. 对整体结构的把握
因为 OpenSSL 和 GnuTLS 的代码量还是比较庞大的。很少有人能把握整体的结构。
2. 对相关协议的了解
想通过看代码分析这两个软件的漏洞,你还需要对相关的协议很熟悉。比如这次的漏洞,就涉及到“心跳协议”的细节。
3. 耐心/恒心
同时具备上述两条的人本来就不多。然后捏,这些人还未必有足够的耐心去把整个代码(哪怕是其中某个模块的代码)通读一遍。
(第三点或许才是最难的)

  如果能够搞定上述三点,并且你的运气足够好,那么你有望独立发现一个高危漏洞。


俺博客上,和本文相关的帖子(需翻墙)
扫盲 HTTPS 和 SSL/TLS 协议(系列)
如何防止骇客入侵(系列)
CNNIC 干过的那些破事儿
CNNIC 证书的危害及各种清除方法
每周转载:关于黑客文化和黑客精神
架构设计:进程还是线程?是一个问题!

97 条评论:

  1. http://thehackernews.com/(黑客新闻) 我是从这里知道的

    回复删除
    回复
    1. TO 2楼的网友
      确实,HN 上有大量的讨论

      删除
  2. 因为博主的博客太有吸引力了,不知不觉的缺乏运动又熬夜身体终于扛不住了(一直头晕脑胀的看什么都看不进去),难受啊!怎么办?

    回复删除
    回复
    1. TO 3楼的网友
      多谢捧场 :)
      但也要注意劳逸结合哦。
      脑力劳动和体力劳动(体育锻炼)搭配,效果才会好。

      删除
    2. 慢慢看啊,累了就睡觉啊

      删除
  3. 刚刷推,看见更新了就滚进来了!

    回复删除
  4. 看了楼主的CNNIC帖子,问个问题,伪造的网站就不能搞个和被它伪造的那个网站一模一样的证书吗?公章可以被伪造,证书不能吗?

    回复删除
    回复
    1. 还有,我曾经问了个风行软件,在我C盘下突然搞出个DLL来,怎么没人感兴趣呢?最开始安装的时候,并没有这个dll。

      删除
    2. 证书本质上是一个公钥和一些附加信息,服务器出示这个,然后你用这个公钥把要跟服务器说的话——我们通信时用哪个对称密钥加密——加密。这样,除了拥有对应的这个公钥的私钥,没人能看到。

      证书上的这个公钥要经过一些上级的CA,认证机构签名。签名是用CA的私钥产生一个数据,确认服务器证书上的信息全部正确,而且确认服务器的所有者和证书上写的一致。这个认证是“实名”的。有了签名的证书,浏览器可以自行验证,最后追溯到一个浏览器自带的“根证书”上。这样就构成了信任链。就是,浏览器确信有一个根证书提供商,然后提供商可信地签署下面的其他提供商,最后有一个认证了这个服务器。

      当然,如果根证书提供商,比如CNNIC,是流氓的话,那么也不行。比如CNNIC有可能利用自己的信誉签署GFW的假证书。然后GFW拿着不会被浏览器报错的证书骗你建立SSL连接,另一方面将你的连接解密后(因为你将消息传给了挂着服务器名字的假证书)用真证书再次加密传给服务器。所谓的中间人攻击。

      所以浏览器里要注意鉴别。国外的这些认证提供商都还是很有信誉的。

      删除
    3. TO test
      你提到的“风行软件”,俺没用过,帮不上忙,抱歉 :(
      关于伪造证书的问题,请看《[url=http://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html]数字证书及 CA 的扫盲介绍[/url]》这篇,里面扫盲了相关的原理

      删除
  5. 我现在不断的研究和学习发现 安全不过只是一个伪命题

    回复删除
    回复
    1. TO 6楼的网友
      关于安全问题的理解
      绝对的安全是不存在的。但是不能因为其不存在就放弃努力。还是可以通过努力,尽可能提高安全程度。
      就好比“绝对零度”是达不到的,但是可以通过努力无限逼近。

      另外,对安全性的努力,要考虑性价比。这时候别忘了对“[url=http://program-think.blogspot.com/2009/02/80-20-principle-0-overview.html]二八原理[/url]”的运用

      删除
    2. 安全的本质是突破安全的代价远远大于保护的内容,就算相对安全了

      删除
  6. 我的评论可能存在一定误解或偏见
    希望您能分析这个话题
    我纠结啦很久

    这是我在思想实验中得到的结果

    回复删除
  7. 各位看youtube用的什么翻墙软件?有快的吗?

    回复删除
    回复
    1. TO 8楼的网友
      有尝试过 VPN gate 吗?
      速度应该还可以的。俺自己的环境中可以达到 150-200 kb/s(字节率)

      删除
    2. vpngate下载链接点,无法加载,请问是什么情况?
      http://www.vpngate.net/cn/download.aspx

      删除
    3. TO 2单元的网友
      VPNgate 的官网需要翻墙才能打开。
      你可以访问它的镜像站点(动态变换网址,无需翻墙就可以下载安装包)。

      删除
    4. 百度youtube吧有很多免翻墙的地址就不知道里面的全不全了

      删除
  8. 我想信NSA肯定掌握了大量的未公开的这种网络安全相关的基础设施级别的漏洞,否则无法做到随意入侵任何目标。请问楼主怎么看?

    回复删除
    回复
    1. TO 9楼的网友
      关于 NSA
      这是公认牛逼机构。据说 NSA 里面包括了全球最顶尖的信息安全专家(尤其是密码学专家)。
      以 NSA 的能力,完全有可能事先分析出 OpenSSL 的漏洞。
      据未经证实的传闻,NSA 内部有一个庞大的团队专门分析开源项目的安全漏洞。

      不过像俺这种人无需担心 NSA 的威胁——俺人在天朝之内,美国政府没有司法管辖权 :)

      删除
  9. 客户端加密,如果浏览器禁用JS,只能不加密传输了?

    回复删除
    回复
    1. TO 瘦肉丝
      如果采用客户端的 JS 脚本进行加密/散列,一旦浏览器禁用 JS 脚本。界面应该提示用户无法登录,而不是发送明文密码。

      删除
  10. Google Now提示博客有更新就趕緊過來看看了

    回复删除
    回复
    1. 哇,怎么设置的google now可以提醒?

      删除
  11. 一直认为在没搞清楚别人的源码前就用别人的开源库是有风险的,看来我的担心是没有错的。最近自己在做高精度数计算的项目(主要是想自己实现RSA加密和Diffie-Hellman密钥交换),参考过OpenSSL,PolarSSL以及LibTomMath的源代码,直观的感受是OpenSSL的代码十分复杂,不容易理解(为了提高效率)。相比之下,PolarSSL就比它简单多了,至少我看完它的源码之后都能够很清楚知道各个代码要干什么。个人认为OpenSSL的代码过于复杂是导致漏洞不易被发现的原因之一。

    回复删除
    回复
    1. TO Curtis Wilbur
      多谢老熟人捧场 :)
      记得很久以前,咱们在邮件中讨论过相关的问题。
      你提到的 PolarSSL 俺不太了解。
      至于 OpenSSL,俺倒是接触了超过10年之久。
      它代码的复杂,不一定都是出于“效率”的考虑。
      还有一个原因是:
      项目的年代久远,会有很多不同的人经手,经手人的水平也是参差不齐。如果缺乏足够好的代码质量控制,会导致代码的紊乱度越来越高(“熵”越来越大)

      另,
      同意你所说——代码结构的复杂会导致难以发现的潜在漏洞。

      不过俺个人觉得:这次的 Heartbleed 漏洞,属于低级错误(太低级了)

      删除
    2. 技术债务 另外加上 历史包袱
      还有code review不到位

      删除
    3. TO 2单元的网友
      多谢补充 :)
      昨天看新闻,据说 OpenSSL 基金会很穷(每年捐款才2000美元)
      也难怪他们人手不够。

      删除
  12. 怎么屏蔽某个特定用户的留言?

    回复删除
    回复
    1. TO 13楼的网友
      BlogSpot 博客系统的留言功能中,没有此项功能。抱歉 :(

      删除
  13. 编程先生一直强调开源,这不是被打脸么?

    哈哈。(无恶意的笑)😊

    回复删除
    回复
    1. TO 14楼的网友
      对于开源,俺还是会一如既往地支持。
      但是俺也会毫不客气地指出开源社区的种种弊端。
      “指出弊端”才有助于今后的进步和发展。

      另外,“闭源软件”因为不开放源代码,导致的问题更大——连代码审计都没法搞。
      开源项目好歹还是可以进行“代码审计”的。问题在于:目前缺乏足够多的志愿者来干这事儿。

      删除
    2. 开源在于共创
      闭源基本上都是出于商业目的

      删除
  14. 提醒一下,除了CNNIC的根证书,应该还有一个China Internet Network 的需要禁用。

    回复删除
    回复
    1. TO cyl@bf2
      多谢提醒 :)
      对于安全性要求较高的网友,最好把天朝之内的 CA 都屏蔽掉。

      删除
  15. 测试了些比特币交易平台 拿到了几个账户
    应该有不少商业网站要遭受损失

    回复删除
    回复
    1. TO BUG
      看来你是“黑帽”:)
      昨天看到报道:对于 Heartbleed 漏洞,如果攻击者运气好,连【私钥】都能拿到。
      所以俺在本文开头提到:Heartbleed 足以载入史册。

      删除
  16. 博主大人说客户端实现散列比在服务端实现散列更安全,原因应该是明文在传输过程中被截获,但是在客户端用脚本实现散列真的安全吗?我在想如果客户端实现散列的脚本被黑阔ko了,那不也完蛋了吗?(菜鸟一只,以上所述如果有可能,请说下客户端实现散列的风险呗;如果没有可能,那就当我yy好了)

    回复删除
    回复
    1. 的确。但是如果这脚本是用https传输的,就没有这种可能。ssl是提供认证服务器身份的。
      然而,如果openssl把私钥都暴露出去了……

      删除
    2. 确实如你所说,如果脚本被中间人攻击,导致使用修改过的脚本替代给你的原始脚本,还是能获取明文密码的,但能进行 HTTPS 中间人攻击的,除了信任根证书机构,没人能做,所以只有 CNNIC 这种可以做到,其他没有信任根证书签名权限的,无法实施这种中间人攻击。1单元的私钥泄露也是一个情况。

      删除
    3. 竟敢伪造我,你还想不想活了???
      我安全局手上还有几百个漏洞呢,对付你们小菜一碟
      编程随想,不要以为我党抓不到你,只是你影响不够大,懒得抓你罢了

      删除
    4. 哎呀,难得见到一回正品忠党爱国啊,普天同庆。

      删除
    5. TO 17楼的网友
      多谢提醒 :)
      那天写得匆忙,没有说详细。
      刚才补充了一个小节——说明了“客户端散列的注意事项和局限性”

      删除
    6. TO 忠党爱国
      你又跑出来吹牛了。
      所谓的“安全局手上还有几百个漏洞”,这是你自己凭空 YY 的吧?

      俺当然也知道朝廷的御用骇客掌握了某些“未公开漏洞”(俺还知道他们手上这些漏洞是从哪来的)
      不过这些漏洞中,只有一小部分是“高品位”的。而且这些漏洞主要针对的都是大众化的操作系统和软件。

      删除
  17. 我做数据库作业都知道在本地端用PHP的sha1函数对密码hash再发到服务器。。

    回复删除
    回复
    1. 现在单纯是sha1已经不算安全了。sha1现在应当算作:不建议在新产品中使用的 那一类算法。
      加salt再散列算是一个选择。不过安全性提高也不大。

      我们要抵抗的是彩虹表攻击,所以应该让产生一个彩虹表字典很费力。
      有些算法,比如PBKDF2、bcrypt、scrypt,允许设置参数,使得散列一个结果非常费力。比如PBKDF2允许1后面N个0的次数的散列,这样就很慢了。而且允许加salt。这样,攻击者就很难拿到结果和salt去挨个尝试。

      与此相比,用时间拖慢计算的,还有用内存作为代价计算的。具体算法没有试过。

      删除
    2. TO 冒牌的忠党爱国
      多谢分享你的经验 :)
      看来你在信息安全方面也有研究 :)

      删除
  18. 我对开源软件的好感大减,因为openssl所暴露出来的问题,居然整个openssl团队只有十个人,这不算什么,重要的是开源软件源代码是开放的,居然没人发现问题,和天朝人民有何差别,我本来还以为外国人认真,现在看来其它开源软件的安全性也好不到哪去

    回复删除
    回复
    1. TO 19楼的网友
      虽然“开源”软件也有弊端,但至少比“闭源”软件还是好很多的。
      在没有更完美的替代品之前,咱们还是得继续用开源的。

      关键是要想办法避免“单点故障”——要多组合几款不同的工具,即使其中一个出问题,也不至于全线崩溃。

      删除
  19. openssl对我打击太大,因为我能做到的我做了,但受到的打击比以前更多更大,如果还要下去,得去编程了,不是那种简单的可视化编程,可能要从更基础的开始才能了解更多细节,但到网络安全我没有天赋,那层我想能学到老学到死

    回复删除
  20. 渣浪微博看到个长微博,按长微博作者的意思,这个漏洞 有点阴谋论的味道。
    http://ww2.sinaimg.cn/large/e11902d2jw1efe8s7qxb4j20c81x947f.jpg

    回复删除
    回复
    1. TO KissKnight
      多谢分享该漏洞的相关网文 :)
      这事儿是有点奇怪,不过还没有充分证据说明源码的漏洞是刻意植入的。

      删除
  21. to 楼主:关于用“撒盐”的方式进行散列,能否就其实现和原理再说具体一点儿?

    回复删除
    回复
    1. 盐(Salt),在密码学中,是指通过在密码任意固定位置插入特定的字符串,让散列后的结果和使用原始密码的散列结果不相符,这种过程称之为“加盐”。
      参考wikipedia:
      https://zh.wikipedia.org/wiki/%E7%9B%90_(%E5%AF%86%E7%A0%81%E5%AD%A6)

      删除
    2. TO cyl@bf2
      多谢替俺回答 :)

      删除
  22. http://xgmyd.com/archives/1325(需翻墙)
    第10届德国之声Bobs新媒体大赛:请为新公民运动等中国候选者投票
    支持许志永!!!

    回复删除
    回复
    1. TO Regis M
      多谢支持 许志永 和 新公民运动 :)

      删除
  23. 秦火火涉嫌在网上侵犯罗援张海迪等人的名誉权,理应由受害人自诉,此案却为何是由执法者提出公诉?既然执法者主动为受害人主张权利,却为何对那些大肆攻击茅于轼为汉奸的造谣者视而不见?法律人在说,这是选择性执法,老百姓在问,为何要选择性执法?法律面前人人平等去哪里了?

    回复删除
    回复
    1. TO 24楼的网友
      咱们朝廷的选择性执法已经有 N年 的历史了。
      所谓的“法制”早已沦为独裁者的工具。

      没有实现政治变革之前,谈“法制”没有太大意义(治标不治本)

      删除
  24. 《耻记》她秘密加入中共,把她爹的大量绝密军事情报传给中共,以致她爹的军事行动屡屡失利,最终向中共投降,仍被毛泽东登报公开羞辱,她爹因此怒骂她“不忠、不义、两姓家奴”。中年时,她被打成“反党分子”,遭到红卫兵的残酷批斗。晚年时,她看不起病,买不起房。她是傅作义的女儿,她叫傅冬菊。

    回复删除
    回复
    1. TO 25楼的网友
      多谢分享 :)
      当年有好多理想主义者被共产运动利用,利用完又像扔垃圾一样无情抛弃。

      删除
  25. 这个漏洞很难说不是故意为之

    回复删除
    回复
    1. TO 26楼的网友
      确实有很多人怀疑 Heartbleed 是人为植入。但是还没有充分证据来证明这点。

      删除
  26. 在Tor自己的网络内(就是从出口节点出去前),openssl会泄露什么信息?(在tor网络外面好像会泄露密码用户名吧,但之间不会透露我的任何信息,我担心的是Tor节点知道我的ip,网络数据,访问网址……请楼主明示)

    回复删除
    回复
    1. TO 27楼的网友
      对于 TOR 网络的节点,如果是“出口节点”,本来就知道你最终访问了哪些网站,如果你访问的网站走的是明文的 HTTP,出口节点还能够知道你的流量内容。(这跟 Heartbleed 漏洞 无关)
      对于入口节点,如果你单独使用 TOR(没有基于“前置代理”),那么 TOR 网络的“入口节点”自然就知道你的公网IP(这跟 Heartbleed 漏洞 也没有关系)。
      更多介绍请看《[url=http://program-think.blogspot.com/2013/11/tor-faq.html]"如何翻墙"系列:关于 TOR 的常见问题解答[/url]》

      删除
  27. http://www.rfa.org/cantonese/firewall_features/firewall-heartbleed-04112014104800.html?encoding=simplified
    “在众多翻墙软件或技术中,除IPSec的VPN,Tor并不依赖OpenSSL的程式库,因此这次漏洞并不会影响 Tor的表现。但其他以加密代理主机为基础的翻墙服务,由于难免会用到OpenSSL,因此全部都会受到影响。”

    https://blog.torproject.org/blog/openssl-bug-cve-2014-0160
    “包含脆弱版的openssl版本的TBB(Tor Browser Bunddle)经过入口节点的诱导,客户端可以告诉他你浏览了什么网站”

    回复删除
    回复
    1. TO 28楼的网友
      后面一篇是 TOR 官方的博文,更有权威性。
      俺倾向于认为:
      TOR 也受到 Heartbleed 漏洞的影响。
      但是 TOR 本身的设计就是基于“多重跳转”,受到的影响比较小。

      删除
  28. 两种说法好像有矛盾,哪个是正确的,到底有多少泄露,请高手明示!

    回复删除
    回复
    1. TO 29楼的网友
      参见俺在 28楼 的留言

      删除
  29. 我也不知道怎么判断,我也用tor,请博主说句话啊?数据传到入口节点前到底泄漏没有啊?我真不想改密码!

    回复删除
    回复
    1. TO 30楼的网友
      关于 TOR 用户受到 Heartbleed 漏洞的影响有多大,需要看几个环节。
      1. 你是单独用 TOR 还是基于双重代理的基础上用 TOR?
      2. “零日阶段”你是否上网访问了自己的敏感账户?
      3. 访问敏感账户的过程中,你是否涉及到“输入密码”环节或者“修改密码”环节?

      删除
    2. 前段时间用TBB一直没发送成功,不好意思迟到了。

      1.我单独使用TBB,如果不是TBB还要看操作系统。
      2.我访问了几乎所有的账户。
      3.输入密码。

      你在28楼1单元说Tor本身设计基于多重跳转,受影响较小。是指密码吗?Tor没说会泄露密码,但泄露访问网站对于我来说已经泄露了我喜欢访问xx网站的性格。。。网址可能是为个人特设的,相当于政府知道我干了什么以及过去干了什么。

      今天我使用tails发贴

      删除
    3. 我没有任何帐号密码以及数据能够指示出本人的身份(我认为的),所以泄漏了也没关系。但是如果入口节点和网站是合谋的,两者就会知道我的真实IP,我在他的网站上搞什么鬼(多数是违法的帖子)等详细资料……

      删除
  30. 嘿 博主你好 我就是刚才问知识管理软件的那个

    对于你说的【客户端加密】,我觉得,即使使用https加密,也会出现安全问题。
    我假设某黑客拿到了某用户的密码hash(比如是qwertyuiop),但是由于是撒过盐的,黑客使用各种方法都没有得到明文。
    怎么办呢?狡猾的黑客使用了如下方法:
    黑客发现网站的登录页面是使用客户端加密计算hash的,并且发现js源码是”$sha1=sha1($password);“(我不会js,不知道有没有语法错误,这里只是打个比方啦),然后它找到火狐的源码,并修改源代码,使得火狐把所有的js代码”sha1($password)“都按照$sha1="qwertyuiop";(就是刚才黑客得到的hash)执行。
    然后黑客编译源代码,得到修改版的火狐。
    后面的操作,博主应该能看出来了吧,进入那个网站登录页面,输入用户名,无论密码输入多少,都可以登录成功的!

    回复删除
    回复
    1. 这里说修改火狐源代码是比较麻烦的,也许黑客更聪明的方法,比如修改浏览器对于登录页面的缓存。。。。(不知道行不行)
      其实我一开始想用一句话描述下这种方法的实质,但是我语言功底实在太差,比我英语还烂,想了半天硬是没有组织出来。。。麻烦博主帮我总结下哈

      删除
    2. 这个问题已经被想到了,解决方法是加入时间戳,使得即使同样内容每次获得的Hash不同。

      删除
    3. 你在将多个层面的问题混为一谈。首先,浏览器自身的安全性是一个问题。这和你用Opera这种闭源浏览器一样——不知道它是否后门。
      我们用的浏览器如果是通过https从mozilla上下载的,或者从tor官网下载(的Tor Browser Bundle)(并验证数字签名),那么可以确认浏览器不做邪恶的事情。

      至于网站使用什么方法储存和验证用户的密码,用什么方案保证登录的用户是当初注册的用户,这是网站的设计的问题。

      https保证的是出现在你浏览器上的东西,和你浏览器传回网站的东西,没有经过篡改,并且旁人无法窃听。如是而已。
      ----

      You are mixing questions from different layers together. Firstly, is the security-related questions from the browser. This applies also to the usage of some closed-source browser like Opera----not knowing the existence of backdoors. Should the browser we use downloaded via https from mozilla, or we download the Tor Browser Bundle from offical tor website and validate its digital signature, we can ensure the browser will not do evil.

      As for how the website stores and validates the user's password, how to ensure the logged user is also the user at registeration, it is the matter of website design.

      https ensures, that what appears on your browser, and what your browser sends back to the server, are not manipulated, and will not be intercepted. That's all.

      ----

      Sie mischte Frage aus unterschiedlichen Schichten ein. Erstens ist die Sicherheitsfrage des Browsers selbst. Dies gilt auch bei der Nutzung von etwa Closed-source Browser wie Opera, denn die Existenz einer Hintertuer wissen wir nicht.

      Wie die Website das Kennwort des Benutzers speichern und ueberpruefen, wie sie versicheren, dass der eingeloggte Benutzer genau den Benutzer beim Registieren ist, ist die Angelegenheit des Entwurfs der Website.

      https versichert es nur, was auf Ihren Browser aufgetaucht ist, und was Ihr Browser zurueckgesandet hat, nicht manipuliert wurde und nicht von anderen abgehoert werden kann. So ist alles.

      删除
    4. 加入时间戳?
      好疑惑,也就是说,hash值会因为时间而改变
      那服务器是如何将计算的hash值与数据库的hash相比较的?

      删除
    5. 除非。。。。服务器储存是明文!但是要是这样搞 hash又有什么意义。。。。‘
      hash的意义在于 即使黑客拿到数据库也无法在短时间内登录用户帐号
      那时间戳是如何运作的的????

      删除
    6. 不要将不同层面的问题混为一谈。我刚刚写了一个很长的回复被删了,等博主恢复出来看吧。

      删除
    7. 你在将多个层面的问题混为一谈。首先,浏览器自身的安全性是一个问题。这和你用Opera这种闭源浏览器一样——不知道它是否后门。
      我们用的浏览器如果是通过https从mozilla上下载的,或者从tor官网下载(的Tor Browser Bundle)(并验证数字签名),那么可以确认浏览器不做邪恶的事情。

      至于网站使用什么方法储存和验证用户的密码,用什么方案保证登录的用户是当初注册的用户,这是网站的设计的问题。

      https保证的是出现在你浏览器上的东西,和你浏览器传回网站的东西,没有经过篡改,并且旁人无法窃听。如是而已。

      顺便:至于安全的存储hash后的密码的方法,不是直接求hash,而是使用PBKDF2或者bcrypt这样的函数,其计算hash需要很长的时间(因为hash函数会被运行很多次)。这些函数也支持使用salt。
      这样黑客即使拿到了单个的hash结果,因为其salt是唯一的,就必须为它单独产生彩虹表。但是这个函数计算单个散列的时间不短,也许1秒钟。这样计算巨大的字典就需要巨大的时间。
      ----

      You are mixing questions from different layers together. Firstly, is the security-related questions from the browser. This applies also to the usage of some closed-source browser like Opera----not knowing the existence of backdoors. Should the browser we use downloaded via https from mozilla, or we download the Tor Browser Bundle from offical tor website and validate its digital signature, we can ensure the browser will not do evil.

      As for how the website stores and validates the user's password, how to ensure the logged user is also the user at registeration, it is the matter of website design.

      https ensures, that what appears on your browser, and what your browser sends back to the server, are not manipulated, and will not be intercepted. That's all.

      BTW: The secure way of storing a password hash, is not calculating it directly, but using functions like PBKDF2 or bcrypt, whose calculations require a very long time(because the hash function will run for a lot of times). Such functions also support salt.
      Therefore, even though the hacker have got a single hash result, because its salt is unique, he must generate a rainbow table for it. But the function's calculation for a single hash requires some not so short time, possibly 1 second, which leads to a large requirement of time in order to calculate a large dictionary.

      ----

      Sie mischte Frage aus unterschiedlichen Schichten ein. Erstens ist die Sicherheitsfrage des Browsers selbst. Dies gilt auch bei der Nutzung von etwa Closed-source Browser wie Opera, denn die Existenz einer Hintertuer wissen wir nicht. Sollten wir den Browser per https aus Mozilla oder offziellen Tor-Website heruntergelanden haetten, und dessen digitale Unterzeichnung bestaetigt haetten, koennen wir glauben, der Browser nichts boese tun wird.

      Wie die Website das Kennwort des Benutzers speichern und ueberpruefen, wie sie versicheren, dass der eingeloggte Benutzer genau den Benutzer beim Registieren ist, ist die Angelegenheit des Entwurfs der Website.

      https versichert es nur, was auf Ihren Browser aufgetaucht ist, und was Ihr Browser zurueckgesandet hat, nicht manipuliert wurde und nicht von anderen abgehoert werden kann. So ist alles.

      Ueberigens, die sichere Methode zum Speichern eines Kennwortes, ist nicht das direkte Ausrechnung von seinem Hashwert, sondern brauchen wir Funktionen wie PBKDF2 oder bcrypt, welche Ausrechungen eine sehr lange Zeit brauchen(weil die Hashfunktionen viele Malen laufen gelassen werden). Solche Funktionen unterstuetzen auch Salz.
      Solange der Hacker das einzige Hashwert bekommen hat, muesste er noch ein erneute Regenbogentabelle dafuer erzeugen, denn der Salz eindeutig ist. Aber der Lauf der Funktion eines einzigen Hashwertes braucht etwas nicht so kurze Zeit, wahrscheinlich eine Sekunde, welche zu einen langen Zeitraum zur Erzeugung des Lexikons fuehren wird.

      是的我就是忠党爱国君,假的。

      删除
    8. 至于加入时间戳什么的,在应对 [浏览器本身出现安全问题] 的情况下,完全没有意义。浏览器完全可以设计成把表单值直接捅出去,不是吗?

      删除
    9. 膜拜楼上大神!为什么如此高大上呢?
      不过!我来弑神!
      如果没有时间戳,设想如此一个情况。黑客截取了你登陆网站时候的所有通信,无论这是加密的与否,他想登陆你的账号的时候只需要重新发送一遍相同的内容就可以了。时间戳是用户验证基本的技巧,当然用明文存储密码的兲朝网站可能没在用,请不要说一个现在被广泛使用的技术毫无价值,尤其是信息安全,这是学术,不是纯粹的商业。
      而且你如何确保开源的浏览器源代码里没有未知的后门?这就是同一个问题。加密的通信协议不能保证下层的安全,无论怎样你无法阻止有人在通讯电缆上安装信息窃取设备。密码学的前提就是什么都是不安全的。有听过那个笑话吗,Alice和Bob在各种恶劣的通讯条件和各种监听下坚持不懈地想秘密且完整地讨论小到婚外情大到逃税的各种勾当……所有的密码学书都在讲这个惊心动魄的故事,没听过就去看点书吧。
      其实我也可以提供2种语言的翻译,但是我还得给楼主解释Hash的工作方式,而且我想睡了……对不起啊稍等
      顺便楼主的说话风格很像那个喵喵的家伙,名字忘了。

      删除
    10. to 7单元:
      我承认时间戳 [[[在浏览器没有问题的情况下]]] 是一种解决方案。但是这只是针对个别问题的解决。如果浏览器不安全,用户输入什么都可以被窃取,那么用户的一切行为都可以被模仿。

      你说的时间戳是在启用了在浏览器端的散列后,继续保证的方法。这样做的问题,如上面某人所说,就必须保证散列之前的结果在服务器有存在,以便服务器可以重新计算并核对。虽然你也可以在客户端用PBKDF2代替简单的散列,但是,js实现的sha的效率和OpenSSL的C语言的实现的效率不是一个数量级的。

      密码学的假设不是什么都是不安全的。数学是安全的。Diffie-Hellman密钥交换是安全的。公开的算法可以是安全的。浏览器的安全问题也不是密码学的问题。Hash的工作方式我不知道,但是它的特性我还是知道的。其实我的爱好也是密码学,虽然不是专业。不过我们讨论问题不必基于对方是否看过书,我们就应该假设对方看过,而不是假设没看过然后借此获取优越感。2种语言的翻译,是因为某层主觉得自己的汉语没有英语好(我是这么理解的)。

      简而言之:请你仔细阅读我的回复的上下文!!!!我重复一遍:请阅读我的回复的上下文!——没有价值是在什么条件下说的?我为什么要这样假设这个条件?我在回复谁?

      删除
    11. 顺便:时间戳类的解决方案,我建议我们考虑下hashcash字符串。这个不但保证了时效性,还是一种proof-of-work,起到类似验证码的作用。前提是,有有效的SHA在浏览器上的实现。

      删除
    12. 另外7单元,我还需要指出一点:现在计算一次hash所用的计算能力已经很强大了。具体技术,也许是GPU,也许是SHA专用芯片,但是我不了解就不提了。我想说的是,在这样的情况下,通过一次hash的结果去反求一个满足构成口令条件的碰撞(用户口令只能是键盘上能输入的那几个字符,长度比如小于20字节,多数还有规律),据说不太困难。

      这样就带来一个问题:你不能认为hash(salt+口令)的计算速度比hash(口令)慢,加了时间戳也是如此。在你的网站的js源码或者服务器源码上,总该能轻易找到用时间戳处理口令的算法。这样,无论你将用户口令通过hash怎样随机地映射到一个值上面,反过来通过穷举求这个口令都未必非常困难。

      这才是我坚持说用PBKDF2来导出口令的原因。PBKDF2在运行时需要口令、salt、循环次数和长度几个变量。根据循环次数的指定,它可以运行——我记得是——2倍的循环次数的hash。推荐的参数比如用1000000次。这样计算单个hash需要的时间也许是1秒,也许是0.1秒,如果有人为了单一用户口令的hash而穷举,就必须面对很长的时间。另外还有bcrypt和scrypt,这里面哪个好像是用巨大的内存作为代价的,比时间更加昂贵。

      总之,问题在于要拖慢穷举的速度。仅仅用hash(salt+口令+时间戳)或者类似的情况,我认为是不够的,即使国内网站都是这样搞——顺便,似乎这些经验是从security.stackexchange.com上面被人经常谈的问题哦~

      删除
    13. 补充10单元的罗嗦一句:
      简而言之,时间戳保证了时效,但是不保证:黑客拿到了一次带着时间戳的登录凭证后,由此通过穷举得到用户的口令——这似乎比重放攻击更加麻烦 :)

      删除
    14. 但是,我还是没有明白,服务器是如何验证带加时间戳一起计算的hash?
      一般情况为了确保安全,服务器是不会储存明文的

      删除
  31. 俺想说,博主的预言:

    俺敢跟任何人打赌,OpenSSL 和 GnuTLS 的代码中,类似的低级错误还有好多。而且 GnuTLS 可能比 OpenSSL 还多。

    已经实现了一点:GnuTLS发现了个和OpenSSL这个漏洞类似的。具体代号没查:(

    回复删除
  32. 回复
    1. TO 33楼的网友
      你这条留言被 Google 误判为垃圾广告,俺刚恢复出来。
      另外,俺看到同一时间还有好几条测试的留言,估计也是你发的。
      由于内容没啥意义,俺就不恢复了。

      删除
  33. http://www.zoomeye.org/lab/heartbleed/2015?port=&code=&f=1

    满满的丧心病狂的味道。。。。。。

    回复删除
  34. 虽然我在一些项目上看到客户端hash,但本人觉得意义不大。

    如果是按照文中,客户端hash,服务端存储的就是这个hash值,那和明文存储没有任何区别。
    如果是我遇到的客户端hash,服务端存储的是客户端hash加盐后的hash,那就是变相提供了一个高强度的随机密码,对安全性略有改善。

    我甚至还遇到过,使用另一套非对称密码系统,专门用来加密敏感数据的方式。但这就是自欺欺人,如果HTTPS被中间人方式攻破,对另一套加密系统使用中间人攻击还不是易如反掌。

    还有,这种hack方式不符合HTTP标准,无法支持HTTP基本认证。总的来说,这些方式并不能提升安全级别,对于能对HTTPS攻击的非菜鸟级黑客来说也就如同包了一层纸而已。

    回复删除