パスワードを忘れた? アカウント作成
11135359 story
セキュリティ

30万台以上のサーバが未だにHeartbleed対策をしていない 20

ストーリー by hylom
先月も同じような話を聞いたような 部門より
あるAnonymous Coward 曰く、

OpenSSLで発見された脆弱性「Heartbleed」が発見されてから2カ月が経過したが、現時点でも少なくみても30万台のサーバーがこれに対し未対策で、無防備な状態にあるという(THE VERGECNET JapanSlashdot)。

Errata Securityのセキュリティ研究者であるRobert David Graham氏によると、発見当初は約60万台のサーバがこのセキュリティ脆弱性に対して無防備な状態であったが、1カ月後には約半数が対策を施され、無防備なサーバは31万8239台に減った。しかし、それから1カ月経過した2カ月後の段階では、新たにパッチが適用されたサーバはわずか9042台しかなかった。残る30万9197台のサーバが依然として無防備な状態にあるとしている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 世界のサーバの全体像が知りたいと思って調べたら
    「全世界のWEBサーバーの数は3億4千万(2011年6月調べ)」 [a-listers.jp]でした。
    見る前にせいぜい1000万台と想像してたらハズレでした。
    今年春のnetcraft統計は英文でApril 2014 Web Server Survey [netcraft.com]
    「30万台のサーバーが無防備」は確かに良くないことだけど、3億台からみたら少ない気がしてきました。

  • by iwakuralain (33086) on 2014年06月26日 10時18分 (#2628025)

    WindowsXPは何万台~
    Heartbleed対策はしたけどPHPは5.2~
    全て最新だけどWordPressは1つ前のバージョン~

    ~ 中略 ~

    Heartbleed未対策サーバー30万台

  • by Anonymous Coward on 2014年06月25日 17時31分 (#2627712)

    CAはその信用を守るためにも、OCSPなりCRLなり使ってRevokeしたほうがいいんじゃないかなー。
    (もちろん何日以内に対応セヨ、と事前に通知することが必要ですが)

    • by Anonymous Coward

      Heartbleed問題は証明書そのものに原因があるのではなく、それを扱うプログラム (openssl) に原因があるわけですから、証明書を無効化したところで問題の解決にはならないでしょう。

      既にCAから顧客に対しては連絡があったはずですし、それ以上の確認コストまでは負担できん、というのが現状ではないでしょうか。

      • by Anonymous Coward

        秘密鍵が盗み出されても、証明書が無効化されていれば悪用できないでしょう?

        • by Anonymous Coward

          そこで「IE6は古くて脆弱性問題もあるだけでなく、証明書無効チェックが標準でされていないんです。だからIE6をすてて新しいOSに(ry」という話も出てきますが(笑)

        • by Anonymous Coward

          証明書が無効化されても問題サーバーをターゲットでメモリーデーターを盗めるのが問題。
          SQLのログイン、ユーザーのログインなどなんでも盗めるのだからSSL鍵の問題ではないのだな。
          CloudFlareは実際にコンテスト(鍵を盗んでみな!)ってやつで数名に盗まれたし。
          http://blog.cloudflare.com/the-heartbleed-aftermath-all-cloudflare-cer... [cloudflare.com]

      • by Anonymous Coward

        > Heartbleed問題は証明書そのものに原因があるのではなく、それを扱うプログラム (openssl) に原因があるわけですから、証明書を無効化したところで問題の解決にはならないでしょう。

        Heartbleed問題で、秘密鍵が盗まれた可能性がある証明書は、その証明書そのものに問題があるということに他ならないのですから、無効化して再生成させる必要がありますよ。

        OpenSSLを修正した後、秘密鍵はそのままでCAから証明書を再発行してもらうなんて間違いも多発したようですが、それがこの30万台に含まれているのか微妙です。
        たぶん含まれていない。

        > 既にCAから顧客に対しては連絡があったはずですし、それ以上の確認コストまでは負担できん、というのが現状ではないでしょうか。

        おそらくCAからの再発行は無償で行ってもらえたはずですし、それをやっていないのは確認コストではなくて、面倒くさい、意味が分からないということだけでしょう。

    • by Anonymous Coward
      CAってそこまで顧客の面倒を見てあげるべき仕事ではないと思うな。

      死ぬほどタコな顧客がうっかり誰でもダウンロード出来るところに秘密鍵を置いていないか? とか、
      考え出すと、ちゃんと面倒を見るために監査しなきゃならない項目が無限に増えて行く。
      • by Anonymous Coward

        > CAってそこまで顧客の面倒を見てあげるべき仕事ではないと思うな。

        は? いやいやいや、何言ってんですかアナタ!
        CAの仕事の本質はそれですよ??

        CAってどういう存在かしってます?

        対象者(サーバやアプリケーション、企業)の存在や安全性を確認したうえでディジタル証明書を発行し、それをユーザに保証してあげることが仕事です。
        安全性の担保が失われた証明書は無効化しないと、仕事をさぼってることになります。

        • by Anonymous Coward
          >CAってどういう存在かしってます?

          対象者がまともかどうか(登記されている企業か、申請者は確かにその企業を代表する立場か)などまで保証出来るような仕組みを目指したけど、
          末端まで徹底できずにぐだぐだになってきたので、本来目指していたところまで徹底的に保証するEV証明書が追加されたという歴史ぐらいまでは知ってます。

          そのEV証明書にしても、申請してきた組織がまともかどうか、また、その組織の総意と見なせる申請かどうかをチェックした上で、
          その組織の秘密鍵にお墨付きを与える証明書を発行するところまでが業務だと思っていましたが、違うんですか?
      • by Anonymous Coward

        だがまぁ秘密鍵を漏らした恐れのある顧客に対して証明書の再発行を行うくらいのサービスはやっても良いんじゃね?
        その一環としてまずは失効処理(予定)と再発行案内(ついでに件のバグの大雑把な説明ととりあえずの対策案内)をやるとかさ。

        パスワード流出したサービスでパスワードを再発行するってのはまま有る事だし、こういう客を放置してSSL/TLSが信用できない状況を改善するってのはCAって業務を行う企業にとってもそう悪いことでは無いと思う。

        • by Anonymous Coward
          一般にはどっちの立場が強いんでしょうね。
          対策をお願いする立場なのか、ある程度強制できる立場なのか。

          非営利無償のCAで、「以前に発効した分は失効手続きを行うので、いついつまでに新しい秘密鍵を作って
          署名リクエストを\送れ」というのをやってのけたところもありましたが。
          その組織がCAをやっている目的が営利ではなく、特定分野のセキュリティ向上なので納得出来る対応でした。

          営利の場合でも、証明書を発行する際の契約に「流出が強く疑われる場合は、確認後、猶予時間をおいて失効させます」と決めておけば良いんですね。
typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...