アカウント名:
パスワード:
「たぶん実害はないから放置しても問題ないだろう」(マーフィーの法則によると、得てしてそういう時に限って問題が含まれている)という不確かで属人的な判断を排除するための規則なのに、例外を認めるのは悪しき前例になりゃしませんかね。
Symantecはそうやって「なあなあ」な態度を取っていたから証明書事業を手放す羽目になったわけですし、その教訓から生まれたCAAレコードでこういうことがあると、Let's Encryptの信用にもかかわるし、「どうせCAAレコードなんて設定しても無駄」という風潮が生まれかねない。
CAAレコードにLet's Encryptを指定するのは正直無意味なような気はするけど。悪意を持った人はまずLet's Encryptを試すだろうし。
CAAレコードを使っていなかったらどのような危険が実質的にあるのでしょうか?偽のDNS情報作られて、SSLも設定されてしまう、というような危険性?
ん? いや、今回問題になっているのは、CAAレコードにLet's Encryptを指定していたケースではなく、Let's Encrypt以外を指定していたケースですよね。ドメイン管理者としては、悪意を持った人がLet's Encryptを試しても証明書を発行できないようにしていたつもりが、実は可能になっていたという話。
ありがとうございます。>ドメイン管理者としては、悪意を持った人がLet's Encryptを試しても証明書を発行できないようにしていたつもりが、
CAAレコードが正しく解釈されていれば、発行されなかったはず、ということですが、悪意を持った人はその証明書をどのようにしてサーバにインストールできるのでしょうか? 別のところで悪用とか可能ですか?
中間者攻撃ができてしまうのでまずいです。
なるほど。
#3775532 [srad.jp]という話もあるようだし、DNSSECもいっしょにやらないと、CAAだけではあまり効果はなさそうですね。うーん、いろいろと設定が必要になるな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
何のための規則なのか (スコア:2, 興味深い)
「たぶん実害はないから放置しても問題ないだろう」(マーフィーの法則によると、得てしてそういう時に限って問題が含まれている)という不確かで属人的な判断を排除するための規則なのに、例外を認めるのは悪しき前例になりゃしませんかね。
Symantecはそうやって「なあなあ」な態度を取っていたから証明書事業を手放す羽目になったわけですし、その教訓から生まれたCAAレコードでこういうことがあると、Let's Encryptの信用にもかかわるし、「どうせCAAレコードなんて設定しても無駄」という風潮が生まれかねない。
Re:何のための規則なのか (スコア:0)
CAAレコードにLet's Encryptを指定するのは正直無意味なような気はするけど。
悪意を持った人はまずLet's Encryptを試すだろうし。
CAAレコードを使っていなかったらどのような危険が? (スコア:0)
CAAレコードを使っていなかったらどのような危険が実質的にあるのでしょうか?
偽のDNS情報作られて、SSLも設定されてしまう、というような危険性?
Re: (スコア:0)
ん? いや、今回問題になっているのは、CAAレコードにLet's Encryptを指定していたケースではなく、Let's Encrypt以外を指定していたケースですよね。
ドメイン管理者としては、悪意を持った人がLet's Encryptを試しても証明書を発行できないようにしていたつもりが、実は可能になっていたという話。
Re: (スコア:0)
ありがとうございます。
>ドメイン管理者としては、悪意を持った人がLet's Encryptを試しても証明書を発行できないようにしていたつもりが、
CAAレコードが正しく解釈されていれば、発行されなかったはず、ということですが、悪意を持った人はその証明書をどのようにしてサーバにインストールできるのでしょうか? 別のところで悪用とか可能ですか?
Re: (スコア:0)
中間者攻撃ができてしまうのでまずいです。
Re: (スコア:0)
なるほど。
#3775532 [srad.jp]という話もあるようだし、DNSSECもいっしょにやらないと、CAAだけではあまり効果はなさそうですね。うーん、いろいろと設定が必要になるな。