アカウント名:
パスワード:
たとえ、脆弱な SSL/TLS 通信であっても HTTP(平文)よりは安全な場合には、アクセス不可にしたり、警告メッセージを表示したりする必要はないでしょう。こういったことがあると、HTTPS から HTTP への移行 [security.srad.jp]が行われるようになり、かえってセキュリティレベルを悪化させます。
どうすれば良いかというと、ブラウザは、脆弱な SSL/TLS に対して鍵マークを表示したりアドレスバーの色を平文通信と変えたりせずに、http(平文)のサイトと全く同じようにユーザーに見せれば良いでしょう。最近のブラウザはアドレスバーをクリックしない限り「http://」を表示しないので、脆弱な
クライアント側でのフォールバックを許すと、中間者攻撃にかなり弱くなりますよ。新しいプロトコルのパケットを妨害することで、強制的に古いプロトコルにフォールバックを起こさせることが可能になるので。
確かに、クライアント側でのフォールバックを許すと、中間者攻撃に対して脆弱です。
しかし、「HTTP(平文)」より危険という訳ではないので、HTTP(平文)で表示されない警告を出したり、接続を拒絶したりする必要はないのでは?
「クライアントサイドでのTLS 1.0へのフォールバックを廃止」して当該サイトへの接続を不可にするのではなく、クライアントサイドでのTLS 1.0へのフォールバックが行われた場合には、ブラウザUI上でユーザーに対してHTTP(平文)と同様の表示を行う(錠アイコンを無しにする、アドレスバーをクリックしない限り「https://」を表示しないなど)という対応で良いと思います。
HTTP(平文)接続の場合、情報を盗み取ることも、改竄することも容易に可能ですが、ユーザーを不安にするような警告ダイアログや、アイコンが表示されることはありません。少なくとも、平文通信と比べて危険という訳ではないのですから、平文通信とUI上の表示を同じにしてしまえば問題が無くなります。安全な通信でないということは「錠アイコンが表示されていない」ことから判別できます。
いや、それではダメです。セッションの途中でTLS 1.0にフォールバックさせられた場合、GETやPOSTのパラメータが予期せず弱いプロトコルで流れてしまいます。やっぱり接続不可は正しいと思いますよ。
HTTPSページからHTTPページにPOST飛ばす時と同じ挙動にすりゃいいだけじゃねぇか。昔IEでは一々警告出てたアレ。HTTPよりは安全だしアレ並にする必要もなさ気だが。
> セッションの途中でTLS 1.0にフォールバックさせられた場合フォールバック先で認証も改竄できるならその懸念も判るけど、そうでなければどこかしら矛盾が出るから検出できるんでない?
そんなことするぐらいなら、現在Firefoxが行っているホワイトリストによる対応の方がはるかにマシですよ。
でも結局、大迷惑なのはこの一件で利用したいサービスが利用出来なくなった利用者な訳で、Google にしてもサービス提供者にしても責任を負うべき。(善悪の判断はこの際置いといて)
たとえばBEASTはTLS 1.1以上で防げるし、Lucky 13はGCMを使った暗号スイート(TLS 1.2が必要)で防げると言っていた人 [security.srad.jp]がいますけど、TLS 1.0へのフォールバックを許していると全く意味がありませんね。まあChromeはBEASTとLucky 13に関しては別の方法で対策していますけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
Google の暴挙がユーザーを危険に晒す (スコア:0)
たとえ、脆弱な SSL/TLS 通信であっても HTTP(平文)よりは安全な場合には、アクセス不可にしたり、警告メッセージを表示したりする必要はないでしょう。こういったことがあると、HTTPS から HTTP への移行 [security.srad.jp]が行われるようになり、かえってセキュリティレベルを悪化させます。
どうすれば良いかというと、ブラウザは、脆弱な SSL/TLS に対して鍵マークを表示したりアドレスバーの色を平文通信と変えたりせずに、http(平文)のサイトと全く同じようにユーザーに見せれば良いでしょう。最近のブラウザはアドレスバーをクリックしない限り「http://」を表示しないので、脆弱な
Re:Google の暴挙がユーザーを危険に晒す (スコア:0)
クライアント側でのフォールバックを許すと、中間者攻撃にかなり弱くなりますよ。新しいプロトコルのパケットを妨害することで、強制的に古いプロトコルにフォールバックを起こさせることが可能になるので。
Re:Google の暴挙がユーザーを危険に晒す (スコア:2)
確かに、クライアント側でのフォールバックを許すと、中間者攻撃に対して脆弱です。
しかし、「HTTP(平文)」より危険という訳ではないので、HTTP(平文)で表示されない警告を出したり、接続を拒絶したりする必要はないのでは?
「クライアントサイドでのTLS 1.0へのフォールバックを廃止」して当該サイトへの接続を不可にするのではなく、クライアントサイドでのTLS 1.0へのフォールバックが行われた場合には、ブラウザUI上でユーザーに対してHTTP(平文)と同様の表示を行う(錠アイコンを無しにする、アドレスバーをクリックしない限り「https://」を表示しないなど)という対応で良いと思います。
HTTP(平文)接続の場合、情報を盗み取ることも、改竄することも容易に可能ですが、ユーザーを不安にするような警告ダイアログや、アイコンが表示されることはありません。少なくとも、平文通信と比べて危険という訳ではないのですから、平文通信とUI上の表示を同じにしてしまえば問題が無くなります。安全な通信でないということは「錠アイコンが表示されていない」ことから判別できます。
Re:Google の暴挙がユーザーを危険に晒す (スコア:1)
表示しようとしているページはプライベートな情報を含むんですから、
HTTP より危険じゃないという理由だけでは採用できません。
Re: (スコア:0)
いや、それではダメです。セッションの途中でTLS 1.0にフォールバックさせられた場合、GETやPOSTのパラメータが予期せず弱いプロトコルで流れてしまいます。やっぱり接続不可は正しいと思いますよ。
Re: (スコア:0)
HTTPSページからHTTPページにPOST飛ばす時と同じ挙動にすりゃいいだけじゃねぇか。
昔IEでは一々警告出てたアレ。HTTPよりは安全だしアレ並にする必要もなさ気だが。
> セッションの途中でTLS 1.0にフォールバックさせられた場合
フォールバック先で認証も改竄できるならその懸念も判るけど、
そうでなければどこかしら矛盾が出るから検出できるんでない?
Re: (スコア:0)
そんなことするぐらいなら、現在Firefoxが行っているホワイトリストによる対応の方がはるかにマシですよ。
Re: (スコア:0)
でも結局、大迷惑なのはこの一件で利用したいサービスが利用出来なくなった利用者な訳で、Google にしてもサービス提供者にしても責任を負うべき。
(善悪の判断はこの際置いといて)
Re: (スコア:0)
たとえばBEASTはTLS 1.1以上で防げるし、Lucky 13はGCMを使った暗号スイート(TLS 1.2が必要)で防げると言っていた人 [security.srad.jp]がいますけど、TLS 1.0へのフォールバックを許していると全く意味がありませんね。まあChromeはBEASTとLucky 13に関しては別の方法で対策していますけど。