パスワードを忘れた? アカウント作成
12505176 story
暗号

Chrome 45のセキュリティ改善により、開けないサイトが現れる(更新) 64

ストーリー by headless
見えないやつが現れる 部門より
あるAnonymous Coward 曰く、

Chrome 45ではセキュリティ改善のため、クライアントサイドでのTLS 1.0へのフォールバックが廃止されたため、HTTPS経由で繋がらないサイトが現れている(ただしHTTP経由で開けるものは多い)。

これは、バギーなサーバーが、仕様に反してTLS 1.0よりも新しいClientHelloを無視するために起こるもので、Chromeは「SSL サーバーが古い可能性があります。」というエラーメッセージを表示する。

ざっと確認したところ、 ヤマト運輸のクロネコメンバーズミスタードーナツダスキン出版社共同ネット競輪J-CASTの東京バーゲンマニア神奈川県教育委員会ネットワークシステム東京学芸大学太平洋フェリー などがHTTPS経由で開けないようだ。

編注: タレこみにあった日本自動車連盟、UCカード、UR都市機構については、他のWebブラウザーでも正常にアクセスできないのでカットした。UCカードは「https://www2.uccard.co.jp/」が現在使われているものとみられ、日本自動車連盟とUR都市機構は暗号化の必要なページのみそれぞれ別ドメインが使われているようだ。また、東京バーゲンマニアのURLにはサブドメインを追加した。

追記 2015/09/09 by headless:
9月9日現在、ミスタードーナツ、ダスキン、太平洋フェリーはサーバーが更新されたとみられ、Chrome 45で上記のURLに問題なくアクセスできるようになっている。

追記 2015/09/10 by headless:
s-books.netが対応済みとなった。また、ヤマト運輸では対応を進めている旨の告知を出している。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2015年09月06日 14時50分 (#2877503)

    Firefoxも、RC4廃止と同時に安全でないフォールバックを無効化する予定 [google.com]。Nightlyではすでに無効化された [mozilla.org]。

    • by Anonymous Coward on 2015年09月06日 17時28分 (#2877537)

      大部分はそこからですね >ネタ元はFirefoxのホワイトリスト
      https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/In... [mozilla.org]
      ap.meitetsuunyu.co.jp
      blogwatcher.co.jp
      keirin.jp
      m.e-hon.ne.jp
      nmsmp.alsok.co.jp
      repair.kuroneko-kadendr.jp
      repairmb.kuroneko-kadendr.jp
      secure.bg-mania.jp
      www.blogwatcher.co.jp
      www.cafedumonde.jp
      www.duskin.co.jp
      www.duskin.jp
      www.jaf.or.jp
      www.matrics.or.jp
      www.misterdonut.jp
      www.my.airdo.jp
      www.pen-kanagawa.ed.jp
      www.session.ne.jp
      www.tealife.co.jp
      www.u-gakugei.ac.jp
      www.uccard.co.jp
      www.ur-net.go.jp
      www3.ibac.co.jp
      www3.taiheiyo-ferry.co.jp
      www.tetsudo.com

      一部はtwitterから。
      cmypage.kuronekoyamato.co.jp
      www.s-book.net

      親コメント
      • by Anonymous Coward

        地銀を追加。
        www.inb.joyobank.chance.co.jp
        www.inb.momijibank.chance.co.jp
        www.inb.yamaguchibank.chance.co.jp
        www.inb.kitakyushubank.chance.co.jp
        www.inb.114dev.chance.co.jp

  • by Anonymous Coward on 2015年09月06日 15時11分 (#2877508)

    で、JavaやUnityやSilverlightが必要なページは一切利用できなくなったわけだが、なぜか窓の杜 [impress.co.jp]もITmedia [itmedia.co.jp]もその他目につくたいていのニュースサイトのどこでも、Flash広告の再生がデフォルトで無効になったとかいうほとんどどうでもいいことしか報じてないんだよな。影響を受けるユーザーはChrome 42の時点ですでに他へ乗り換えるなりしたってことなのかな。

    • by Anonymous Coward on 2015年09月06日 17時32分 (#2877541)

      いま世間で普通に認知されてて、JavaやSilverlightが必要なページってちょっと思いつかないなぁ
      GyaoがかつてSilverlight使ってたのくらいか。

      Flash広告はしょっちゅう勝手に動いてうっとおしいってことで存在は認識してるんで、無効化はありがたい。
      しかしそれでさえほとんどどうでもいいことだっていうなら、Javaやらなんやらの廃止がそれ以上に影響のある話題とも思えないなぁ。
      デベロッパーにとっては大事っていうなら、Flash広告の無効化だって同様に大事な話のはずだしね。

      # 個人的には、囲碁・将棋関係のサイトがJavaアプレット全盛期に作られたまま放置されてるのは
      # なんとかしてほしいと思うが、ニュースにするべき話とも思わない。

      親コメント
    • by Anonymous Coward on 2015年09月06日 19時51分 (#2877581)

      NPAPIが使えないとvSphereの管理画面が動かないのですよね
      VMWare社非公式ではHTML5版を公開してるけどまだ開発途上版だし

      親コメント
    • by Anonymous Coward on 2015年09月07日 9時14分 (#2877721)

      DMMとか、とってもUnityなんですが、まだUnity側では対応プラグインを配布されていないようで…
      http://www.dmm.com/netgame/ [dmm.com]

      親コメント
    • by Anonymous Coward

      そりゃ「廃止しても困る人ほとんどいないだろうから廃止するね」で廃止されたので。

      • by Anonymous Coward on 2015年09月06日 16時07分 (#2877519)

        2014年10月の時点 [chromium.org]でもSilverlightの使用率は11%、すでに既定で無効化されていたJavaですら3.7%あった。「ほとんどいない」にはほど遠い。
        普通UseCounterで機能の廃止に踏み切るときのしきい値は0.03%なので、政治的な理由で廃止したと言わざるをえない。

        親コメント
        • by Anonymous Coward on 2015年09月06日 17時44分 (#2877546)

          そりゃまぁセキュリティ的に問題が多かったり、ご本家からも
          見捨てられることが確定したりしてるような技術群ですし…。

          ていうか「0.03%しかユーザがいないから廃止しても問題ない」だって立派に政治的な判断ですし、
          そもそも政治的な判断がなされることに何の問題があるんでしょう。

          親コメント
        • by Anonymous Coward

          >「ほとんどいない」にはほど遠い。
          見解の相違というやつですね、3.7%は私にとっては「ほとんどいない」です。

        • by Anonymous Coward

          >Javaですら3.7%
          それだけの割合のひとが有効にしてただけで、実際に使ってたというデータはないのでは。
          SilverlightもWindowsUpdate時に知らずにインストールしただけって人も多いと思う。

          • by Anonymous Coward

            最近の Java は Applet は昔からのしがらみ以外では使われて無くて、
            新しくクライアント Java で作られるサービスはJava Web Start が多いと思う。

    • by Anonymous Coward

      Hulu を Chrome で見ると内蔵 Flash player のためコマ落ちが発生します。
      そのため、NSAPI 版のオフィシャル Flash player を使う回避策がありました。
      しかし、今回のバージョンからその回避策は使用不可になりました。

      Chrome 44 にダウングレードして解決しましたが、救済措置まで消すのは早すぎる気がします。

  • >ミスタードーナッツ https://www.misterdonut.jp/ [misterdonut.jp]
  • by Anonymous Coward on 2015年09月06日 15時00分 (#2877505)

    うちのサイトも開けませんでした。
    まあfc2の無料スペースだからなあ。

    • by Anonymous Coward

      FC2の無料ホームページってHTTPSが使えるの?

  • by Anonymous Coward on 2015年09月06日 15時20分 (#2877510)

    Firefoxでも見ても崩れている(IEだと大丈夫)ので、バグが顕著化しただけっぽいですが・・・。

  • by Anonymous Coward on 2015年09月06日 15時28分 (#2877511)

    ログインや決済に対してならいい判断なんだけど
    Googleって通常ページもHTTPS化推奨してたような。。。
     
    これだと梯子外すことになっちゃうんで
    むしろHTTPへ逆行しちゃうんじゃないかな
    それとも通常ページもHTTPS化推進は諦めたのかな

    • Re:水至清即無魚 (スコア:2, 参考になる)

      by Anonymous Coward on 2015年09月06日 15時33分 (#2877512)

      ここでは接続できなくなったサイトばかりことさらに取り上げてるけど、TLS 1.0へのフォールバックが必要なサイトはUseCounter [hatenablog.com]で(四捨五入後)0.00%だったというデータに基づいて廃止に踏み切ったんんだよ。

      親コメント
    • by Anonymous Coward on 2015年09月06日 16時19分 (#2877523)

      無償製品はそういうものという合意はあると思うけど、Googleは移行猶予の確保に消極的だよな。
      有償主体の企業や、顧客機会喪失に敏感な弱小企業とはそういう所が違うと思う。
      悪とは違うと思うが好感度がいまいち。

      親コメント
      • Re:水至清即無魚 (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2015年09月06日 22時29分 (#2877641)

        Googleみたいなところが甘やかすといつまで経っても移行しないからね。
        メンテナンスコストは常時かけておかないといけないという現実に鈍感すぎる企業は特に。

        親コメント
      • by Anonymous Coward

        >無償製品はそういうものという合意はあると思うけど、Googleは移行猶予の確保に消極的だよな。

        どんだけ待てば気が済むんだよw

  • by Anonymous Coward on 2015年09月06日 16時03分 (#2877517)

    ベンダカスタムapacheてこと?本家apacheは問題なし?

  • by Anonymous Coward on 2015年09月06日 17時25分 (#2877536)

    >ただしHTTP経由で開ける
    これてどいうことですか?
    実際に試したらそうだったというだけですか?

    本来はHTTPとHTTPSはアクセス出来るところが異なるはずです。(あえて一緒にしてなければ)

  • by Anonymous Coward on 2015年09月06日 17時32分 (#2877540)

    ここまでしないとウイルスとかヤバイのかな?
    それとは別に、44辺りからすごく重くなった。
    低スペックどんどん切り捨てられていく…。
    セキュリティのせいもあるのかもしれんけどね。

    • by Anonymous Coward on 2015年09月06日 20時13分 (#2877593)

      今回の件はウイルスではなく、中間者攻撃(盗聴やメッセージすり替えを行う攻撃)の問題ですので、ネットバンキングやネットショッピングを始めとする重要な情報のやり取りの安全性の話ですね。
      近年、安全なプロトコルとされてきたSSL/TLSの脆弱性が多く発見されているものの、それらの問題への対処はまだ道半ばなので、今後も更にセキュリティ強化が進むでしょうね。

      親コメント
  • たとえ、脆弱な 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

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

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

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

        しかし、「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

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

    • by Anonymous Coward

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

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

      by Anonymous Coward

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

    • by Anonymous Coward

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

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

typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...