アカウント名:
パスワード:
基本的に新しめで安全な方式を優先でいいが、古いのを禁止までする必要があるのか疑問
サーバの秘密鍵が漏れるような脆弱性がないかぎり、別に禁止までする必要は無いでしょ?
6年前、まさに秘密鍵が漏れるような脆弱性があったんだよなぁ
DROWN脆弱性ね、と思ったら4年前(2016年)だな。他になんかあったっけ?
BEASTとかPOODLEとかHeartbleedが2013-2014年頃
Heartbleedは古いプロトコルを有効にしていたことが原因ではない気がするし(むしろセキュリティプロトコルに新機能をむやみに導入してバグ入れた感じ)、BEASTやPOODLEは「有効にしているだけで秘密鍵が漏れる」脆弱性ではないような
さすがに単に古すぎるからなんて理由で「非推奨」とは別にわざわざ「禁止」カテゴリを作ったりはしない
SSL 3.0について言えば、POODLE攻撃により部分的であれど解読できることが判明しているのだから、禁止するのが妥当ではないでしょうか?
自己レス、POODLEはCBCの場合だけでしたね。とは言え、SSL 3.0からCBCを取り除くとRC4を使う暗号スイート(またはNULL)しか残らず、SSL 3.0で安全な通信はもはや達成できないということになるかと思います。
脆弱性の修正などでWebブラウザは新しいものに更新し続ける必要のあるものですから、古いものを残し続けるメリットなんてほとんど無いように思います。更新の止まっている環境は、使うこと自体が危険なので、リプレースが必要でしょう。
このようなガイドラインを出されても読まない文盲で傲慢の老害に、TLS等のセキュリティ設定の重要さを分からせるために、どう説得するのか、IPAはどのような情報を発信するべきだろうか。
という意味ですね。まさか本気で言っている訳ないですよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
古いのを禁止までしなくてもいいのでは? (スコア:0)
基本的に新しめで安全な方式を優先でいいが、
古いのを禁止までする必要があるのか疑問
サーバの秘密鍵が漏れるような脆弱性がないかぎり、
別に禁止までする必要は無いでしょ?
Re: (スコア:0)
6年前、まさに秘密鍵が漏れるような脆弱性があったんだよなぁ
Re: (スコア:0)
DROWN脆弱性ね、と思ったら4年前(2016年)だな。他になんかあったっけ?
Re: (スコア:0)
BEASTとかPOODLEとかHeartbleedが2013-2014年頃
Re: (スコア:0)
Heartbleedは古いプロトコルを有効にしていたことが原因ではない気がするし(むしろセキュリティプロトコルに新機能をむやみに導入してバグ入れた感じ)、BEASTやPOODLEは「有効にしているだけで秘密鍵が漏れる」脆弱性ではないような
Re: (スコア:0)
さすがに単に古すぎるからなんて理由で「非推奨」とは別にわざわざ「禁止」カテゴリを作ったりはしない
Re: (スコア:0)
SSL 3.0について言えば、POODLE攻撃により部分的であれど解読できることが判明しているのだから、禁止するのが妥当ではないでしょうか?
Re: (スコア:0)
自己レス、POODLEはCBCの場合だけでしたね。とは言え、SSL 3.0からCBCを取り除くとRC4を使う暗号スイート(またはNULL)しか残らず、SSL 3.0で安全な通信はもはや達成できないということになるかと思います。
Re: (スコア:0)
脆弱性の修正などでWebブラウザは新しいものに更新し続ける必要のあるものですから、古いものを残し続けるメリットなんてほとんど無いように思います。
更新の止まっている環境は、使うこと自体が危険なので、リプレースが必要でしょう。
Re: (スコア:0)
このようなガイドラインを出されても読まない文盲で傲慢の老害に、TLS等のセキュリティ設定の重要さを分からせるために、どう説得するのか、IPAはどのような情報を発信するべきだろうか。
という意味ですね。まさか本気で言っている訳ないですよね。