パスワードを忘れた? アカウント作成
14129888 story
暗号

Let's Encrypt、証明書およそ300万件の強制失効処理を取りやめ 39

ストーリー by headless
影響 部門より
Let's Encryptでは標準に準拠せずに発行した可能性のある証明書およそ300万件を3月5日12時までに失効させる計画を示していたが、最終的に取りやめたそうだ(Let's Encrypt Community Supportの記事[1][2]MozillaのBugzillaArs Technicaの記事The Registerの記事)。

この問題はLet's EncryptのCAソフトウェアBoulderがCAAレコードを再チェックするコードのバグが原因で発生した。Let's Encryptではドメイン所有者確認を30日間有効としているが、CAAレコードは証明書発行の8時間以内のチェックが必要だ。そのため、ドメイン所有者確認から8時間以上経過した証明書発行申請に対してはCAAレコードの再チェックが行われることになる。しかし、申請にN個のドメインが含まれていた場合、Boulderは1個のみを選択してN回チェックしていたとのこと。これにより、ドメイン所有者確認後にLet's Encryptによる証明書発行を禁ずるCAAレコードがインストールされたドメインにも証明書を発行していた可能性がある。

Boulder にバグが追加されたのは2019年7月25日で、バグは2月29日に確認された。影響を受ける可能性のある証明書の大半にセキュリティリスクはないとみられるが、標準に準拠せずに発行した証明書は失効させる必要があるという業界の取り決めに従い、Let's Encryptが発行したアクティブな証明書の2.6%に相当する3,048,289件の失効処理を3月5日5時に開始すると発表。CAAレコードでLet's Encryptによる証明書発行が禁じられていた445件の証明書をはじめ、既に置き換えられているものや使われていないもの計1,711,396件はコンプライアンス期限の5日12時までに失効処理を完了した。しかし、残る1,336,893件のうち65%はインターネットスキャンで使用中であることが確認され、あとの35%は状態を確認できなかったとのこと。

そのため、強制的に証明書を失効させない方がインターネット利用者の利益にかなうと判断したそうだ。その後、295,799件の証明書を6日までに失効処理しており、37,499件は失効処理する前に期限切れになったという。Let's Encryptが発行する証明書の有効期限は90日間であり、影響を受ける証明書は今後、毎日数千~数万件が有効期限を迎えることになる。失効処理を行わなくても5月29日にはすべて期限切れとなるが、利用者に影響を与えないと確信し次第、より多くの証明書の失効処理を行う計画とのことだ。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ぐええ (スコア:5, おもしろおかしい)

    by minet (45149) on 2020年03月08日 18時35分 (#3775323) 日記

    申請にN個のドメインが含まれていた場合、Boulderは1個のみを選択してN回チェックしていたとのこと。

    ぐあぁぁ
    (なにかトラウマが刺激されたらしい)

    • by minet (45149) on 2020年03月09日 11時03分 (#3775548) 日記

      これだけじゃ何のことか分からんという人のために、
      丁寧に解説してくださっているブログを見つけたので参照。
      Let's EncryptがはまったGolangの落とし穴 [hatenablog.com]

      これは、ループ内でループ変数iの参照を配列に入れてしまうことで、ループ終了後の出力値が
      (…中略)
      のように配列が全て同じ値になってしまう問題です。

      for や range などで扱うループ変数が同じ参照になることを知っていないとやってしまいそうな初心者的な間違いです。
      (…中略)
      これはひょっとしたら自分もいつかこのようなバグを仕込んでしまうかも、と背筋が寒くなりました。

      親コメント
      • by Anonymous Coward

        Goはよくわからんので「Goでよくある間違い」をC++に移植してみた。

        #include <iostream>
        #include <vector>
         
        int main() {
            std::vector<int*> out;
            for (int i = 0; i < 3; ++i) {
                out.push_back(&i);
            }
            std::cout << "Vaues: " << *out[0] << " " << *out[1] << " " << *out[2] << std::endl;
            std::cout << "Addresses: " << out[0] << " " << out

        • by Anonymous Coward

          あ、iのスコープはforループの中だから見事に鼻から悪魔が出てた。

              int i;
              for (i = 0; i < 3; ++i) {

          こうしないとダメか。C++だといかにも不自然になるな

      • ループ変数の値でなく参照を配列に積んでいくって、どう考えたらそういう発想になるのか判らないのですが...
        Goだと、参照を渡すのがほぼ常だとかいうのがあるのでしょうか。

    • by Anonymous Coward

      ぺろっ。
      こ、これは並列処理?!

  • 延期で正解 (スコア:3, 興味深い)

    by Anonymous Coward on 2020年03月08日 13時17分 (#3775197)

    3月に入ってcertbotでの更新がエラー吐く

    原因は古い情報が消えず新仕様に適応できないため

    その原因はcertbotが依存するpython2時点の情報とpython3時点の情報が混在しているため

    解消方法はcertbot、python-certbot-*、python-letsencrypt-*を一旦removeして再install
    # それでもだめならpurge後に再install
    # 依存関係でぞろぞろ出てくるので弊害がでるものがないかは要確認

    予定通り強行してたら2週間で原因究明と対処を自前で何とかしろ状態でしたので
    更新できなかった方々が大量に出たのではないでしょうか

    # 延期が予定通りなら良い演習だったとは思う

    • by Anonymous Coward

      おま環

      • by Anonymous Coward

        おま環

        ある意味正しい
        python3から始めたなら起こらない不具合
        python2から使っていてpython3へ跨いだなら発症する不具合

        /*
        ただしcertbotが依存移行する際に遺した負の遺産のため
        正しい意味での「おま環」ではないことに注意
        */

        • by Anonymous Coward

          RHEL6 (CentOS 6) でcertbotを素直に使ってるとはまるやつなので相当数はまったと思う

  • by Anonymous Coward on 2020年03月08日 14時43分 (#3775234)

    「たぶん実害はないから放置しても問題ないだろう」(マーフィーの法則によると、得てしてそういう時に限って問題が含まれている)という不確かで属人的な判断を排除するための規則なのに、例外を認めるのは悪しき前例になりゃしませんかね。

    Symantecはそうやって「なあなあ」な態度を取っていたから証明書事業を手放す羽目になったわけですし、その教訓から生まれたCAAレコードでこういうことがあると、Let's Encryptの信用にもかかわるし、「どうせCAAレコードなんて設定しても無駄」という風潮が生まれかねない。

    • by Anonymous Coward

      今後同様の大規模なrevokeが必要になったときのために、revoke予告の通知を受けて証明書の再発行と置き換えまで自動的にやるシステムを構築するって言ってるよ。

    • by Anonymous Coward

      CAAレコードにLet's Encryptを指定するのは正直無意味なような気はするけど。
      悪意を持った人はまずLet's Encryptを試すだろうし。

      • CAAレコードを使っていなかったらどのような危険が実質的にあるのでしょうか?
        偽のDNS情報作られて、SSLも設定されてしまう、というような危険性?

      • by Anonymous Coward

        ん? いや、今回問題になっているのは、CAAレコードにLet's Encryptを指定していたケースではなく、Let's Encrypt以外を指定していたケースですよね。
        ドメイン管理者としては、悪意を持った人がLet's Encryptを試しても証明書を発行できないようにしていたつもりが、実は可能になっていたという話。

        • by Anonymous Coward

          ありがとうございます。
          >ドメイン管理者としては、悪意を持った人がLet's Encryptを試しても証明書を発行できないようにしていたつもりが、

          CAAレコードが正しく解釈されていれば、発行されなかったはず、ということですが、悪意を持った人はその証明書をどのようにしてサーバにインストールできるのでしょうか? 別のところで悪用とか可能ですか?

          • by Anonymous Coward

            中間者攻撃ができてしまうのでまずいです。

            • by Anonymous Coward

              なるほど。

              #3775532 [srad.jp]という話もあるようだし、DNSSECもいっしょにやらないと、CAAだけではあまり効果はなさそうですね。うーん、いろいろと設定が必要になるな。

    • by Anonymous Coward

      そのうち失効するからって業界の取り決めに従って失効させないCAを今後も信頼するんですかMozillaさん!

      https://it.srad.jp/story/18/03/01/072235/ [it.srad.jp]

      • by Anonymous Coward

        はじめは失効させるつもりだったのを取りやめたのは、どこかから反対が出たような気がするんだよな。
        大量失効させるとユーザがブラウザのrevocatioチェックを無効化するからやめてくれとMozillaさん達がお願いしてたりして。

    • by Anonymous Coward

      「たぶん実害はないから放置しても問題ないだろう」

      たぶん動くからリリースしようぜ!

    • by Anonymous Coward

      >「どうせCAAレコードなんて設定しても無駄」

      いや、無駄ですよね?
      DV証明書を不正発行させるには、対象ドメインを何らかの方法で乗っ取る必要があって、
      直接DNSを乗っ取れたならCAAレコードごと書き換えできちゃうし、
      DNSではなくHTTPやメールのみの乗っ取りに留まる場合でも、
      CAAに記載されたCAから別の証明書を発行させることはできるんだから。
      せめてDNSSECがMUSTになっていればまだ救いはあるのになってないし。

  • by Anonymous Coward on 2020年03月08日 22時42分 (#3775391)

    リンク先によれば、「大量の証明書を一度にrevokeすると、ユーザーはブラウザの設定を変更してrevocatioチェックを無効化するだろう。そのようなユーザーはおそらく問題が収まっても設定を戻したりしない」というのが理由らしい。まあわからんでもない。

    We believe that revoking those actively in-use certificates would have harmed the web because many users, upon encountering the revocation errors, would look up instructions on how to bypass revocation checks. For instance, the top Google result for [SEC_ERROR_REVOKED_CERTIFICATE firefox] right now is https://support.mozilla.org/en-US/questions/856276 [mozilla.org], which says 'You can uncheck "Use the OCSP to confirm the current validity"'. Those users are unlikely to re-enable revocation checks once they are done using the affected sites. This would prevent those users from receiving future warnings about revoked certificates.

    • by Anonymous Coward

      どんな理由があろうとも例外なく厳格に運用することに意義があるのではなかったのか

      • by Anonymous Coward

        いわゆる真面目なバカという一番害のあるやつですね。

    • by Anonymous Coward

      なるほどなぁ。確かにわからんでもないけど、そういうユーザーは本当に偽証明書が使われていた場合にも同じ行動を取るだろうから、保護するに値しないとも思う。

      • by Anonymous Coward

        設計ミスを運用でカバーさせようとして、運用がミスると逆ギレですか。

    • by Anonymous Coward

      デフォルトの設定が証明書エラーを数クリックで無視できる今のブラウザってどいつもこいつもおかしいよね

    • by Anonymous Coward
      証明書を無効化するようなブラウザ設定は期限付きにすれば良いのでは?
      • by Anonymous Coward

        それだと、そのためだけに新しい機能を作ってメンテナンスし続けないといけないからね。

  • この手の些細なミスはなかったことにすればよかった

    • こういうのがSymantecにいたせいで致命傷になったんやろなあ。BoulderのソースはGitHubで公開されてるからごまかすのは不可能だし

      親コメント
    • by Anonymous Coward

      それをやるとブラウザへのバンドルが不可能になって廃業しなきゃいけなくなるんだよ

      • by Anonymous Coward

        もともと3か月で失効するLet's Encryptは大目に見てもいい気はするが。

        • by Anonymous Coward

          Google・Microsoft・Aapple・Mozillaが
          「異常発覚から5日以内に失効させること」に合意した証明機関だけバンドルしてる。
          それを事前に「3ヶ月にしてくれ」って言うべきだね。

  • by Anonymous Coward on 2020年03月08日 21時57分 (#3775381)
    サーバ証明書ってCPSなりBaseline Requirementsに従って運用されることが大前提だと思うので、「影響が大きいから失効させない」という判断が認められるならいろいろおかしなことになるのでは。
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...