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

Let's Encryptでは標準に準拠せずに発行した可能性のある証明書およそ300万件を3月5日12時までに失効させる計画を示していたが、最終的に取りやめたそうだ(Let's Encrypt Community Supportの記事[1]、 [2]、 MozillaのBugzilla、 Ars 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日にはすべて期限切れとなるが、利用者に影響を与えないと確信し次第、より多くの証明書の失効処理を行う計画とのことだ。

ぐええ

[minet (45149)]

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

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

補足ね

[minet (45149)]

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

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

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

Re:

[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

Re:

[Anonymous Coward]

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

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

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

「よくある間違い」なの？

[Anonymous Coward]

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

Re:「よくある間違い」なの？

[albireo (7374)]

Let's encryptのバグはRustで実装していたら防げたの？ [qiita.com]によると

実際のLet's encryptの実装ミスは、ループの中で関数呼び出しを挟んでいるので
気づくのが難しいとも感じました。

だそうで、積んでるのが参照だということを見落としやすい形になっていたのかも

--
うじゃうじゃ

Re:

[Anonymous Coward]

そりゃ問題を示すための最小限のコードなんだからわざとらしいに決まってるだろ。「どうしてオブジェクト指向では犬や猫を鳴かせるのかさっぱり」みたいな言いがかりだな

Re:

[Anonymous Coward]

ぺろっ。
こ、これは並列処理？！

Re:

[Anonymous Coward]

並列以前な部分だぞ

延期で正解

[Anonymous Coward]

3月に入ってcertbotでの更新がエラー吐く
↓
原因は古い情報が消えず新仕様に適応できないため
↓
その原因はcertbotが依存するpython2時点の情報とpython3時点の情報が混在しているため
↓
解消方法はcertbot、python-certbot-*、python-letsencrypt-*を一旦removeして再install
# それでもだめならpurge後に再install
# 依存関係でぞろぞろ出てくるので弊害がでるものがないかは要確認

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

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

Re:

[Anonymous Coward]

おま環

Re:

[Anonymous Coward]

おま環

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

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

Re:

[Anonymous Coward]

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

何のための規則なのか

[Anonymous Coward]

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

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

CAAレコードを使っていなかったらどのような危険が？

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

なるほど。

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

Re:

[Anonymous Coward]

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

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

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

Re:

[Anonymous Coward]

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

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

ユーザーがrevocation checkを無視するから

[Anonymous Coward]

リンク先によれば、「大量の証明書を一度に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.

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

修正して3か月以上たってからバグに気付いたことにすればよかったのに

[Anonymous Coward]

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

Re:修正して3か月以上たってからバグに気付いたことにすればよかったのに

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

Re:

[Anonymous Coward]

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

なんで？

[Anonymous Coward]

サーバ証明書ってCPSなりBaseline Requirementsに従って運用されることが大前提だと思うので、「影響が大きいから失効させない」という判断が認められるならいろいろおかしなことになるのでは。