パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Chrome 45のセキュリティ改善により、開けないサイトが現れる(更新)」記事へのコメント

  • たとえ、脆弱な SSL/TLS 通信であっても HTTP(平文)よりは安全な場合には、アクセス不可にしたり、警告メッセージを表示したりする必要はないでしょう。こういったことがあると、HTTPS から HTTP への移行 [security.srad.jp]が行われるようになり、かえってセキュリティレベルを悪化させます。

    どうすれば良いかというと、ブラウザは、脆弱な SSL/TLS に対して鍵マークを表示したりアドレスバーの色を平文通信と変えたりせずに、http(平文)のサイトと全く同じようにユーザーに見せれば良いでしょう。最近のブラウザはアドレスバーをクリックしない限り「http://」を表示しないので、脆弱な https の場合には http に倣って、アドレスバーをクリックするまで「https://」の文字も表示しないようにすれば良いでしょう。そうすれば、ユーザーは http と同様の信頼のサイトとみなすことになるので、セキュリティ上の問題は生じません。

     

     ~ここから先は SHA-1 脆弱性対応に関する Google への批判です ~

    SHA-2 証明書への移行についても、Google の対応には問題があります。そもそも、SHA-1 → SHA-2 の移行スケジュールについては、2013年11月にMicrosoftが SHA-2 への移行を発表し、かなり前に Microsoft・認証局・業界団体等の間で、

    1. 2015年12月 : SHA-1 証明書の新規発行をまでに停止
    2. 2016年12月 : SHA-1 証明書の利用終了

    ということでコンセンサスが得られていたはずです。

    IE や Mozilla Firefox などのブラウザも、これに従い、2017年1月以降に SHA-1 証明書の拒否(Firefox は加えて、2016年以降に発行された証明書に警告を表示)というスケジュールでの移行を行うとしています。

    ところが、Google だけが自己中心的な暴挙に出て、業界のコンセンサスを無視した強行な移行を行おうとして、Chrome 39(2014年11月リリース)で証明書の有効期限が2016年以降のSHA-1証明書のhttps接続の際に、鍵マークを警告アイコンにするといった行為を行いました。

    確かに、SHA-1 の脆弱性問題については、数ある SSL/TLS 脆弱性の中でも例外となる珍しいセキュリティ上の問題でして、SHA-1で署名を偽造してSHA-2の署名付き証明書に見せかけることができるため、SHA-1のサポートをブラウザから完全に廃止するしかありません。「http(平文)のサイトと全く同じようにユーザーに見せれば良い」というのも当てはまりません。

    しかし、SHA-1 に脆弱性が新たな脆弱性が発見されたのではなく、CPU・GPUの性能向上で解読にかかる時間が徐々に減っているというだけのことで、強度が弱いのは10年以上前からわかっていたことです。業界のコンセンサスから勝手に1年前倒しする理由にはなりません。

    また、証明書の移行というのは企業にとっては大がかりなタスクとなります。一部の顧客を切り捨てることになるわけなので、顧客に周知したり、代替手段を用意したりする必要があります。例えば、銀行だったら、普通の脆弱性のように技術部門がパッチをあてて終わりというようなものではなく、かなり上の役職の人が行う会議での議決が必要になるでしょう。また、電話サポートの人員を増やすといった対応も必要となります。スケジュールが急な結果、みずほ銀行のWebサイト(ネットバンキングを除く)は、HTTPS → HTTP のみ → 批判を受けて HTTPS 版を復活 → 最終的に HTTP(平文)のみにするといったことになり、「SHA-2への移行」ではなく「HTTPへの移行」となってしまいました。

    Google の暴挙によって、ユーザーは、メガバンクを含む大手金融機関などの有名サイト [mizuhobank.co.jp] でも壊れた鍵アイコンを頻繁に見にすることになりました。それにより、ユーザーはこういったセキュリティ上の警告が表示されることに慣れてしまい、セキュリティ警告が出たとしても気にせず続行するようになってしまいました。例えば、HTTPS 通信の中に広告(外部JavaScript)が含まれていて、その外部JavaScriptがHTTP通信の場合には通信が改竄されると危険が生じるわけですが、そういった暗号化されていないスクリプトが混ざっている場合の「壊れたアイコン」も、殆どのユーザーは気にしなくなったのでは? 結果として、Google の暴挙は、多くの一般ユーザーを危険に晒すことになりました。

    • by Anonymous Coward on 2015年09月06日 18時00分 (#2877548)

      いやいやいや、今回の件は、どう考えてもIIS 5.0とかApache 1.3系/2.0系を使っているサーバーの方が問題でしょう。とっくのとうにサポート切れてますよ。アクセス不可にするのは正解ですって。

      親コメント
    • by Anonymous Coward

      そりゃ難癖、言いがかりのレベルだなぁ

      もっと早く対処すればいいだけの話でしょ、それこそ昔からわかってたんなら当然
      コンセンサス?なにそれ。それで誰が救われるのかと言えば業界だけで、ユーザーは救われないじゃん
      暴挙というならそれ早く死に物狂いでなんとかしろよ、ユーザー守るために
      それをしないならやっぱり無能だし、なんかやってるGoogleが有能ってだけでしょ

    • by Anonymous Coward

      ガラケーユーザにも配慮を、、、と携帯会社の中の人が設定変更を拒否したケースがあると聞いたが、、、
      まぁ人伝なのでガセだろう。

      • by Anonymous Coward

        某システム屋ですが、ガラケーからのアクセスを許容しつつ最新化も可能ですよ?

      • by Anonymous Coward

        SHA2対応してるガラケーあるにも関わらず
        SHA2の件でこれ幸いとガラケーサポート切ったところならちらほら知ってます

        • by Anonymous Coward

          Twitter とか LINE とか Biglobe とか?

    • by Anonymous Coward

      クライアント側でのフォールバックを許すと、中間者攻撃にかなり弱くなりますよ。新しいプロトコルのパケットを妨害することで、強制的に古いプロトコルにフォールバックを起こさせることが可能になるので。

      • クライアント側でのフォールバックを許すと、中間者攻撃にかなり弱くなりますよ。新しいプロトコルのパケットを妨害することで、強制的に古いプロトコルにフォールバックを起こさせることが可能になるので。

        確かに、クライアント側でのフォールバックを許すと、中間者攻撃に対して脆弱です。

        しかし、「HTTP(平文)」より危険という訳ではないので、HTTP(平文)で表示されない警告を出したり、接続を拒絶したりする必要はないのでは?

        「クライアントサイドでのTLS 1.0へのフォールバックを廃止」して当該サイトへの接続を不可にするのではなく、クライアントサイドでのTLS 1.0へのフォールバックが行われた場合には、ブラウザUI上でユーザーに対してHTTP(平文)と同様の表示を行う(錠アイコンを無しにする、アドレスバーをクリックしない限り「https://」を表示しないなど)という対応で良いと思います。

        HTTP(平文)接続の場合、情報を盗み取ることも、改竄することも容易に可能ですが、ユーザーを不安にするような警告ダイアログや、アイコンが表示されることはありません。少なくとも、平文通信と比べて危険という訳ではないのですから、平文通信とUI上の表示を同じにしてしまえば問題が無くなります。安全な通信でないということは「錠アイコンが表示されていない」ことから判別できます。

        親コメント
        • by Anonymous Coward on 2015年09月07日 9時43分 (#2877734)
          情報のコンテキストをちゃんと考えて下さい。
          表示しようとしているページはプライベートな情報を含むんですから、
          HTTP より危険じゃないという理由だけでは採用できません。
          親コメント
        • by Anonymous Coward

          いや、それではダメです。セッションの途中でTLS 1.0にフォールバックさせられた場合、GETやPOSTのパラメータが予期せず弱いプロトコルで流れてしまいます。やっぱり接続不可は正しいと思いますよ。

          • by Anonymous Coward

            HTTPSページからHTTPページにPOST飛ばす時と同じ挙動にすりゃいいだけじゃねぇか。
            昔IEでは一々警告出てたアレ。HTTPよりは安全だしアレ並にする必要もなさ気だが。

            > セッションの途中でTLS 1.0にフォールバックさせられた場合
            フォールバック先で認証も改竄できるならその懸念も判るけど、
            そうでなければどこかしら矛盾が出るから検出できるんでない?

            • by Anonymous Coward

              そんなことするぐらいなら、現在Firefoxが行っているホワイトリストによる対応の方がはるかにマシですよ。

        • by Anonymous Coward

          でも結局、大迷惑なのはこの一件で利用したいサービスが利用出来なくなった利用者な訳で、Google にしてもサービス提供者にしても責任を負うべき。
          (善悪の判断はこの際置いといて)

      • by Anonymous Coward

        たとえばBEASTはTLS 1.1以上で防げるし、Lucky 13はGCMを使った暗号スイート(TLS 1.2が必要)で防げると言っていた人 [security.srad.jp]がいますけど、TLS 1.0へのフォールバックを許していると全く意味がありませんね。まあChromeはBEASTとLucky 13に関しては別の方法で対策していますけど。

    • by Anonymous Coward

      平文なサイトもまとめて
       「危険なサイトに接続しようとしています」
      と表示してあげたほうがシンプルで理解しやすいし、親切だと思う。
      そこから先は自己責任で。

      • by Anonymous Coward

        僕もこれが一番だと思う。
        銀行とかなんで対応遅いんだよってユーザーが意識できるのは良い事。

      • by Anonymous Coward

        激しく同意。
        問題は、最近のブラウザが”自己責任による自由”を悉く認めなくなって来ている事なんだよね。
        Chrome は言うに及ばず、Firefox も Chrome を真似てそういう方向に傾いて来てるし、Edge は未完成商法で論外だし。

      • by Anonymous Coward

        まったくだ。
        ちょっと訂正するならざっくり「危険」ではなく「通信の安全性が存在しない」とかにしときたいが。

        # HTTPの平文→通信の安全性が存在しないサイトに接続しようとしています
        # 脆弱HTTPS→通信の安全性が低下しているサイトに接続しようとしています
        # 推奨HTTPS→通信の安全性が確認されているサイトに接続しようとしています
        # 俺俺証明書→危険なサイトに接続しようとしています
        # # で、フィンガープリント表示して、正規のものであると確認させてから記録して記憶するオプションも出しておく

    • Re: (スコア:0, オフトピック)

      by Anonymous Coward

      #2877544 のドコが「参考になる」んだ???

    • by Anonymous Coward

      普通の人は、httpsかhttpかの違いしかわからない。(それさえも知らない人多い)
      httpsだけど危ないかもよ、っていうのがわからない。だからクリックしてhttpsだったらOKになってしまう。

      オレオレ証明書の場合は警告でるけど、それと同じような扱いでいいと思うけどね。

      • by Anonymous Coward
        まぁ拒絶の是非はおいとくとしても

        > 普通の人は、httpsかhttpかの違いしかわからない。(それさえも知らない人多い)
        > httpsだけど危ないかもよ、っていうのがわからない。だからクリックしてhttpsだったらOKになってしまう。

        だから、もう使えなくしちゃえば安全になるじゃないかという発想なんでしょう。
        そもそも危険なもん公開している方が問題だろう。
        というスタンス。

        見るための物は無料で手に入る(Chrome以外もある)。
        セキュリティを唱えても中途半端に使えると浸透しないのはメールだとかFTPだとか無くならない状況を見ればわかるしね。

        癒着と知識不足が多い大企業では(サーバー変更しないととかWebサーバーアプリ買い直さないととか)必要以上に金かかるのでそう簡単な話ではないんだがね(直ちに解決できない現実問題としてね)。

        # HTTPS everywhereはいいんだけどSSL証明書つくんのもなにかとめんどくさいし金もかかるしその辺なんとかしてくれんもんかね。

にわかな奴ほど語りたがる -- あるハッカー

処理中...