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が対応済みとなった。また、ヤマト運輸では対応を進めている旨の告知を出している。
接続できないサイトのネタ元はFirefoxのホワイトリストかな? (スコア:5, 参考になる)
Firefoxも、RC4廃止と同時に安全でないフォールバックを無効化する予定 [google.com]。Nightlyではすでに無効化された [mozilla.org]。
Re:接続できないサイトのネタ元はFirefoxのホワイトリストかな? (スコア:4, 参考になる)
大部分はそこからですね >ネタ元は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
Re: (スコア:0)
地銀を追加。
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
NPAPIのサポートが完全終了 (スコア:2, 興味深い)
で、JavaやUnityやSilverlightが必要なページは一切利用できなくなったわけだが、なぜか窓の杜 [impress.co.jp]もITmedia [itmedia.co.jp]もその他目につくたいていのニュースサイトのどこでも、Flash広告の再生がデフォルトで無効になったとかいうほとんどどうでもいいことしか報じてないんだよな。影響を受けるユーザーはChrome 42の時点ですでに他へ乗り換えるなりしたってことなのかな。
Re:NPAPIのサポートが完全終了 (スコア:1)
いま世間で普通に認知されてて、JavaやSilverlightが必要なページってちょっと思いつかないなぁ
GyaoがかつてSilverlight使ってたのくらいか。
Flash広告はしょっちゅう勝手に動いてうっとおしいってことで存在は認識してるんで、無効化はありがたい。
しかしそれでさえほとんどどうでもいいことだっていうなら、Javaやらなんやらの廃止がそれ以上に影響のある話題とも思えないなぁ。
デベロッパーにとっては大事っていうなら、Flash広告の無効化だって同様に大事な話のはずだしね。
# 個人的には、囲碁・将棋関係のサイトがJavaアプレット全盛期に作られたまま放置されてるのは
# なんとかしてほしいと思うが、ニュースにするべき話とも思わない。
Re:NPAPIのサポートが完全終了 (スコア:2, 参考になる)
GyaoはChromeのMac版が64bit化したことで視聴できなくなってSilverlightやめたみたいだけど、動画配信サイトや証券取引のサイトを中心にSilverlight使っているところはまだある。dTV [dmkt-sp.jp]とかWOWOWメンバーズオンデマンド [wowow.co.jp]とか損保ジャパン [sjnk.co.jp]とかDMM.com証券 [dmm.com]とか(後ろの2つなんかChromeがサポート対象に入ったまま更新されてないぞ)。
Re:NPAPIのサポートが完全終了 (スコア:1)
むしろ、今年7月の Windows Server 2003サポート終了に伴って、WMRM SDK（Windows Media PlayerのDRM絡み）のサポートが終了した影響で、動画サイトのWMP⇛Silverlight製プレーヤーへの移行により、1年前よりもSilverlight利用サイトが増えているのが現状です。
Google : windowsmediaplayer 終了 Silverlight インストール [google.co.jp]
なぜ日本の動画サイトがそこまでして茨の道を歩きたがるのかよくわかりません。
Re:NPAPIのサポートが完全終了 (スコア:1)
NPAPIが使えないとvSphereの管理画面が動かないのですよね
VMWare社非公式ではHTML5版を公開してるけどまだ開発途上版だし
Re:NPAPIのサポートが完全終了 (スコア:1)
DMMとか、とってもUnityなんですが、まだUnity側では対応プラグインを配布されていないようで…
http://www.dmm.com/netgame/ [dmm.com]
Re: (スコア:0)
そりゃ「廃止しても困る人ほとんどいないだろうから廃止するね」で廃止されたので。
Re:NPAPIのサポートが完全終了 (スコア:1)
2014年10月の時点 [chromium.org]でもSilverlightの使用率は11%、すでに既定で無効化されていたJavaですら3.7%あった。「ほとんどいない」にはほど遠い。
普通UseCounterで機能の廃止に踏み切るときのしきい値は0.03%なので、政治的な理由で廃止したと言わざるをえない。
Re:NPAPIのサポートが完全終了 (スコア:1)
そりゃまぁセキュリティ的に問題が多かったり、ご本家からも
見捨てられることが確定したりしてるような技術群ですし…。
ていうか「0.03%しかユーザがいないから廃止しても問題ない」だって立派に政治的な判断ですし、
そもそも政治的な判断がなされることに何の問題があるんでしょう。
Re: (スコア:0)
>「ほとんどいない」にはほど遠い。
見解の相違というやつですね、3.7%は私にとっては「ほとんどいない」です。
Re: (スコア:0)
>Javaですら3.7%
それだけの割合のひとが有効にしてただけで、実際に使ってたというデータはないのでは。
SilverlightもWindowsUpdate時に知らずにインストールしただけって人も多いと思う。
Re: (スコア:0)
最近の Java は Applet は昔からのしがらみ以外では使われて無くて、
新しくクライアント Java で作られるサービスはJava Web Start が多いと思う。
Re: (スコア:0)
Hulu を Chrome で見ると内蔵 Flash player のためコマ落ちが発生します。
そのため、NSAPI 版のオフィシャル Flash player を使う回避策がありました。
しかし、今回のバージョンからその回避策は使用不可になりました。
Chrome 44 にダウングレードして解決しましたが、救済措置まで消すのは早すぎる気がします。
いちおう「ミスタードーナツ」なんで (スコア:1)
Re:いちおう「ミスタードーナツ」なんで (スコア:1)
うちのも (スコア:0)
うちのサイトも開けませんでした。
まあfc2の無料スペースだからなあ。
Re: (スコア:0)
FC2の無料ホームページってHTTPSが使えるの?
デザイン崩れなども多数 (スコア:0)
Firefoxでも見ても崩れている（IEだと大丈夫）ので、バグが顕著化しただけっぽいですが・・・。
Re:トピ違いだけど (スコア:2)
追加。
・CSSで、まだベンダープレフィックスをつけないと使えない（＝まだ仕様が流動的な）スタイルを使おうとしていて、-webkit-と-ms-は書いてあるけど-moz-が無いか、書き方を間違っている。（同様の機能で-moz-だけ書式が違うことはよくある）
・ChromeとIEでは実装済みの機能だけど、Firefoxはまだ実装が追いついていない。
・サーバー側でユーザーエージェントを判定して異なるスタイルシートを適用するようにしているが、判定を間違っている。
水至清即無魚 (スコア:0)
ログインや決済に対してならいい判断なんだけど
Googleって通常ページもHTTPS化推奨してたような。。。
これだと梯子外すことになっちゃうんで
むしろHTTPへ逆行しちゃうんじゃないかな
それとも通常ページもHTTPS化推進は諦めたのかな
Re:水至清即無魚 (スコア:2, 参考になる)
ここでは接続できなくなったサイトばかりことさらに取り上げてるけど、TLS 1.0へのフォールバックが必要なサイトはUseCounter [hatenablog.com]で(四捨五入後)0.00%だったというデータに基づいて廃止に踏み切ったんんだよ。
Re:水至清即無魚 (スコア:1)
無償製品はそういうものという合意はあると思うけど、Googleは移行猶予の確保に消極的だよな。
有償主体の企業や、顧客機会喪失に敏感な弱小企業とはそういう所が違うと思う。
悪とは違うと思うが好感度がいまいち。
Re:水至清即無魚 (スコア:2, すばらしい洞察)
Googleみたいなところが甘やかすといつまで経っても移行しないからね。
メンテナンスコストは常時かけておかないといけないという現実に鈍感すぎる企業は特に。
Re: (スコア:0)
＞無償製品はそういうものという合意はあると思うけど、Googleは移行猶予の確保に消極的だよな。
どんだけ待てば気が済むんだよｗ
バギーなサーバ (スコア:0)
ベンダカスタムapacheてこと？本家apacheは問題なし？
Re:バギーなサーバ (スコア:5, 興味深い)
クロネコのサーバは Server: Fjapache/8.0 (Unix) というヘッダを付けてますね。4.1 Interstage HTTP Server（Apache 2.0ベース）への移行 [fujitsu.com]をみると、これは Apache 1.3ベースのようです。だとすると Apache 1.3 を使っていると引っかかるかも知れません。
# 富士通さんは平然と 20世紀のものを持ってくるという印象を持っています。
Re:バギーなサーバ (スコア:3, 興味深い)
あるパッケージで開発リーダー？がソース持ってきて話したことあるけど、中身泥団子状態。
ソース見て唖然とした。
ここまで汚くなる前にリファクタリングしなかったの？と言ったら上が許さないらしい。
同じ指摘する人はソレなりに居るし、修正しづらくて嫌気さすとも。。
Re:バギーなサーバ (スコア:1)
いろんなファイルに fj って接頭辞がついてて
これは見なかったことにすべき事案だな、と思った。
Re:バギーなサーバ (スコア:1)
ただしHTTP経由で開ける (スコア:0)
>ただしHTTP経由で開ける
これてどいうことですか？
実際に試したらそうだったというだけですか？
本来はHTTPとHTTPSはアクセス出来るところが異なるはずです。（あえて一緒にしてなければ）
Re:ただしHTTP経由で開ける (スコア:1)
無題 (スコア:0)
ここまでしないとウイルスとかヤバイのかな？
それとは別に、44辺りからすごく重くなった。
低スペックどんどん切り捨てられていく…。
セキュリティのせいもあるのかもしれんけどね。
Re:無題 (スコア:1)
今回の件はウイルスではなく、中間者攻撃(盗聴やメッセージすり替えを行う攻撃)の問題ですので、ネットバンキングやネットショッピングを始めとする重要な情報のやり取りの安全性の話ですね。
近年、安全なプロトコルとされてきたSSL/TLSの脆弱性が多く発見されているものの、それらの問題への対処はまだ道半ばなので、今後も更にセキュリティ強化が進むでしょうね。
Google の暴挙がユーザーを危険に晒す (スコア:0)
たとえ、脆弱な 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・認証局・業界団体等の間で、
ということでコンセンサスが得られていたはずです。
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 の暴挙は、多くの一般ユーザーを危険に晒すことになりました。
Re:Google の暴挙がユーザーを危険に晒す (スコア:3, すばらしい洞察)
いやいやいや、今回の件は、どう考えてもIIS 5.0とかApache 1.3系/2.0系を使っているサーバーの方が問題でしょう。とっくのとうにサポート切れてますよ。アクセス不可にするのは正解ですって。
Re: (スコア:0)
そりゃ難癖、言いがかりのレベルだなぁ
もっと早く対処すればいいだけの話でしょ、それこそ昔からわかってたんなら当然
コンセンサス？なにそれ。それで誰が救われるのかと言えば業界だけで、ユーザーは救われないじゃん
暴挙というならそれ早く死に物狂いでなんとかしろよ、ユーザー守るために
それをしないならやっぱり無能だし、なんかやってるGoogleが有能ってだけでしょ
Re: (スコア:0)
ガラケーユーザにも配慮を、、、と携帯会社の中の人が設定変更を拒否したケースがあると聞いたが、、、
まぁ人伝なのでガセだろう。
Re: (スコア:0)
某システム屋ですが、ガラケーからのアクセスを許容しつつ最新化も可能ですよ？
Re: (スコア:0)
SHA2対応してるガラケーあるにも関わらず
SHA2の件でこれ幸いとガラケーサポート切ったところならちらほら知ってます
Re: (スコア: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)
たとえばBEASTはTLS 1.1以上で防げるし、Lucky 13はGCMを使った暗号スイート(TLS 1.2が必要)で防げると言っていた人 [security.srad.jp]がいますけど、TLS 1.0へのフォールバックを許していると全く意味がありませんね。まあChromeはBEASTとLucky 13に関しては別の方法で対策していますけど。
Re: (スコア:0)
平文なサイトもまとめて
「危険なサイトに接続しようとしています」
と表示してあげたほうがシンプルで理解しやすいし、親切だと思う。
そこから先は自己責任で。
Re: (スコア:0, オフトピック)
#2877544 のドコが「参考になる」んだ？？？
Re: (スコア:0)
普通の人は、httpsかhttpかの違いしかわからない。(それさえも知らない人多い)
httpsだけど危ないかもよ、っていうのがわからない。だからクリックしてhttpsだったらOKになってしまう。
オレオレ証明書の場合は警告でるけど、それと同じような扱いでいいと思うけどね。