Google、Chromeで混合コンテンツを完全にブロックする計画 52
ストーリー by headless
計画 部門より
計画 部門より
Googleは3日、Gooogle Chromeで混合コンテンツを完全にブロックする計画を発表した(Chromium Blogの記事、 VentureBeatの記事、 Android Policeの記事、 SlashGearの記事)。
混合コンテンツはHTTPSページのサブリソースがHTTP接続で読み込まれる状況を指し、Chromeを含む現在のブラウザーのほとんどがスクリプトやiframeといった危険性の高い混合コンテンツをブロックする。一方、比較的危険性が低いと考えられる画像や音声、動画については読み込みが許可されるが、偽の画像への差し替えや、トラッキングcookieの挿入といった攻撃を受ける可能性もある。
Chromeでの混合コンテンツ完全ブロック計画は段階的に行われる。まず、12月に安定版がリリースされるChrome 79ではサイト単位で混合コンテンツのブロックを解除可能なオプションが設定に追加され、現在はブロックされているスクリプトやiframeの読み込みを許可できるようになる。
Chrome 80ではHTTPSページで音声と動画のリソースをHTTP接続で読み込むよう指定されている場合、HTTPS接続に自動アップグレードして読み込みを試みる。HTTPSでの読み込みが失敗した場合はデフォルトでブロックされるが、先述のオプションで読み込みを許可することも可能だ。画像の混合コンテンツは引き続き許可されるが、読み込まれた場合はHTTPページと同様に「保護されていない通信」という表示がOmnibox左端に追加される。
Chrome 81では画像の混合コンテンツも自動アップグレードの対象となり、HTTPS接続で読み込めない場合はデフォルトでブロックされるとのこと。Chrome 81は2020年3月に安定版リリース予定となっている。
混合コンテンツはHTTPSページのサブリソースがHTTP接続で読み込まれる状況を指し、Chromeを含む現在のブラウザーのほとんどがスクリプトやiframeといった危険性の高い混合コンテンツをブロックする。一方、比較的危険性が低いと考えられる画像や音声、動画については読み込みが許可されるが、偽の画像への差し替えや、トラッキングcookieの挿入といった攻撃を受ける可能性もある。
Chromeでの混合コンテンツ完全ブロック計画は段階的に行われる。まず、12月に安定版がリリースされるChrome 79ではサイト単位で混合コンテンツのブロックを解除可能なオプションが設定に追加され、現在はブロックされているスクリプトやiframeの読み込みを許可できるようになる。
Chrome 80ではHTTPSページで音声と動画のリソースをHTTP接続で読み込むよう指定されている場合、HTTPS接続に自動アップグレードして読み込みを試みる。HTTPSでの読み込みが失敗した場合はデフォルトでブロックされるが、先述のオプションで読み込みを許可することも可能だ。画像の混合コンテンツは引き続き許可されるが、読み込まれた場合はHTTPページと同様に「保護されていない通信」という表示がOmnibox左端に追加される。
Chrome 81では画像の混合コンテンツも自動アップグレードの対象となり、HTTPS接続で読み込めない場合はデフォルトでブロックされるとのこと。Chrome 81は2020年3月に安定版リリース予定となっている。
実効性はないな (スコア:0)
現状ミクスドコンテンツなんて
技術力のない一般であって
悪用としてあるわけじゃない
むしろハックされて
差し込まれてる部分だけHTTPS
みたいな笑えないことも
改善して無くなったほうが良いのは確かだけど
お題目としての相手はとっくに外部呼び込みもHTTPSしてる
受動的コンテンツのHTTPS強制も無意味だし
# 証明書をちゃんと確認する一般人なんかいねぇよみたいな
Re: (スコア:0)
ほんとそれな。
わざわざミックス化して抵抗意思表示したいって奴も出てくるんじゃね。
それ自体が重大なセキュリティリスク作ってるのでない限り、
ブラウザごときがそんな個々の実装方針に口出す資格はねぇよ。
一時のIEよりも明白に邪悪だ。
Re:実効性はないな (スコア:1)
なんかな。
現状のIE11でさえかなり以前から混合コンテンツって既定で動作しないようになってるんだぜ。
今更イメージ等を許す必然はもうないだろ。
そもそも出所不明なリソースを読み込めるってのは重大なセキュリティリスクと化してるだろ。
悪意あるサイトをhttps化するのは簡単だが、そもそもの脅威は通信中のリソースの差し替えへの対策なんだから悪意あるサイトがhttps化されようがどうでもいい。
しかし動画はブロックしないのか。中途半端な。
Re: (スコア:0)
どうでもいいHTTPな外部サイトの画像を参照するたびに自前にキャッシュしたり
リンク化して別タブで開いたりってーのもアホらしいっていうか危ないと思うがな。
HTTPで通信内容がすり替えられて別の画像が表示される程度のリスクより、
悪意があるかもしれない任意コンテンツをキャッシュして自前のサーバで配信しちゃったり、
画像っぽいURLで画像じゃないコンテンツにリンクを張ってしまう方が怖い。
素直に外部画像として読み込んで変なの来たら破損画像扱いする方が遥かに安全じゃない？
画像として読んでも問題があるエクスプロイトとかはミックス以前にHTTP全部塞がにゃ無意味だし。
Re: (スコア:0)
素直に外部画像として読み込んで変なの来たら破損画像扱いする方が遥かに安全じゃない？
何をもって変なのと判断するんだろう？
そもそもすり替えられたら困るリソースの配信は端からhttpsで行うべきで、
うん、だからhttpsにするんだよ。
「どうせてめぇらには無理だから死ね」？「雑兵の体力なんて知らねぇよボケ」？
無理なら死ね。迷惑だ。
Re: (スコア:0)
> 何をもって変なのと判断する
画像として読めない以外に現時点で破損画像扱いされるレスポンスがあるのか？
HTTPサイトの画像を参照させるに当たり、
imgタグで読ませればhtml帰ってきても無視されて終わりだが、
リンクで直に開かせたらhtml帰ってきてスクリプト実行されて、
場合によってはCSRFされてと面倒事が増えるだろうがバカめ。
> うん、だからhttpsにするんだよ。
君、人の話を聞かないってよく言われるだろ。
差し替えられても困らない、第三者のサーバの画像とかの話だぞ？
差し替えられて困るようなリソースはhttps採用する段階でht
Re: (スコア:0)
邪悪だと言うのは簡単だし、実際そういう側面はあるだろうけど、現実的に「邪悪じゃない」ビジネスモデルでシェアが取れるかというと疑問だし、シェアが取れなきゃ（Webサービス提供者や開発者に）相手にされないしなぁ。
Re: (スコア:0)
邪悪なM$(笑)全盛期には誰もそんなこと言ってなかったけどね
Re: (スコア:0)
邪悪なM$(笑)全盛期には誰もそんなこと言ってなかったけどね
Linuxがとって変わるって騒いでた人は一定数いたよ。
コンシューマーOSという分野では、どうなんだろうね。
AndroidをLinuxの一種とみなせば、ある意味、それなりに成功している。その結果がChromeの邪悪化っていう様だけど。
デスクトップOSという意味ではLinuxなんてオワコン以前にはじまってすらいないままだな。
Re: (スコア:0)
これに関しちゃシェアって意味ではマイナスで、
シェア取ってるからこそWebのルールを私物化できる類の話だろう。
IEの場合、私物化なのか囲い込みなのかただの不具合なのか判別しかねるが…
Re: (スコア:0)
HTTP3やらQUICやらを推していく前仕込みか何かかね
Re: (スコア:0)
「お題目としての相手」って誰？ 想定してる悪用ケースが違わない？
Re: (スコア:0)
> ミクスド
# 今朝のシンカリオンの再放送でアドバンスドモードがお披露目
Re: (スコア:0)
えー、iframeでst-hatenaとか読み込まれるたびにCPUがガンガン走り出して、熱い空気が排気口から噴き出すんだよ。
もうやめてほしいわ。
Re: (スコア:0)
えー、iframeでst-hatenaとか読み込まれるたびにCPUがガンガン走り出して、熱い空気が排気口から噴き出すんだよ。
HTTPSで読み込まれてるものは今後もスルーなわけだが
Re: (スコア:0)
そういうのは拡張機能「uMatrix」等を入れて、same-origin以外のiframeをブロックするといいよ
Re: (スコア:0)
Manifest v3で独自のブロックポリシーを持つ拡張機能は終了のお知らせでしょ?
wikiみたいなサイト (スコア:0)
将来画像の混合コンテンツまでブロックとなると、
wikiみたいな利用者が任意の画像URLを登録できるサイトではすごい面倒なことになりそう
Re: (スコア:0)
無関係のドメインの画像を直接インライン表示出来るwikiサービスってあんまなくね。
Re: (スコア:0)
世の中にはPukiwikiというものがありましてね・・・
Re: (スコア:0)
リンク画像を設置しているサーバーのドメイン管理者がドメインの期限を切らせて乗っ取られてしまうかもしれないだろ!
ご参考: https://srad.jp/story/05/09/07/0923246/ [srad.jp]
Re: (スコア:0)
将来画像の混合コンテンツまでブロックとなると、
wikiみたいな利用者が任意の画像URLを登録できるサイトではすごい面倒なことになりそう
実装側で置き換え強制すればいいだけでは?
Re: (スコア:0)
そうでなくても、通販サイトとかで、Webサイト（HTMLの出力）は自前ドメイン、商品画像とかはaws等で管理してリンク埋め込み、みたいな実装はちらほら見かけるけど、そういう実装が死ぬね。
Re:wikiみたいなサイト (スコア:1)
何故死ぬんだ？
aws等へのリンクがhttpsになってれば何の問題もないだろ。
とんちんかんにもほどがあるぞ。
Re: (スコア:0)
ドメイン丸ごと同じにすればいいじゃん、20年前じゃあるまいし、画像や重いファイルだけ別ドメインにする理由ないでしょ。時代遅れだよ。
Re: (スコア:0)
20年前じゃあるまいし、画像や重いファイルだけ別ドメインにする理由ないでしょ。
固定IPじゃないクラウドリソースにDNSの設定するの面倒じゃん。
自前のロードバランサーとか使うとその分、金がかかるわけで、だったらクラウド側で勝手に使えるドメイン名をそのまま使う方が合理的。
Re:wikiみたいなサイト (スコア:1)
Route53 に CloudFront の名前を alias として設定するだけだし、
面倒という程ではない。
Re: (スコア:0)
画像が別ドメインになった理由って、その１つはブラウザ側が紳士協定でコネクション2つぐらいしか貼れないからじゃなかったっけ。
今は時代遅れな感じ？
Quicにすればそんな配慮せず1ドメインでいいんだろうけど…手段のための目的という感じがする。
Re: (スコア:0)
Chromeが禁止したいのはhttpsのページにhttpのリソースを使われる事だけじゃね？
Re: (スコア:0)
そもそもどんな URL でも登録できる WiKi は少ない。(javascript: とか file: とかで悪戯されるので)。
利用者の安全のため、本来なら、WiKi は数年前に http:/// [http] で始まる URL を登録できなくするべきだった。
南京錠アイコン表示しなけりゃいいだけ (スコア:0)
混合コンテンツの完全ブロックはセンスの無い施策としか言いようがない。
混合コンテンツの場合には、httpと同じで、南京錠を表示しなければ良いだけ。
現状でもGoogle Chromeは https://srad.jp/ [srad.jp] にアクセスしても、アドレスバーには 「srad.jp」としか表示されず（「https://」は省略される）、http なのか https なのかはクリックしないと分からないようになっている。
そのため、混合コンテンツの場合に、アドレスバーに「https://」があるから画像等も改竄されていないはずだといった誤解を招く心配もない。
基本的に普通のhttpと同じ表示にして、アドレスバーをクリックした場合に、画像が改竄されている恐れがある旨の警告を出せば良いだろう。
そもそも、混合コンテンツが生じる理由は、管理者が違う画像を表示したい場合などやむを得ない場合があるケースがあり、混合コンテンツになることを防ぐためにサイト全体を https から http に戻さなければならなくなったらかえって安全性が低下する。
Re: (スコア:0)
いずれhttpを禁止するんじゃね？
Re:南京錠アイコン表示しなけりゃいいだけ (スコア:1)
たとえば阿部寛のサイトがhttpsである必要はないと思う
Re:南京錠アイコン表示しなけりゃいいだけ (スコア:1)
阿部寛のサイトは機密性の高い情報を扱う訳ではないので、httpsである必要はないというのはその通り。
一方、有名人のサイトは中間者攻撃により「こちらから寄付をお願いします」等と攻撃者のサイトに誘導してお金を振り込ませたり、クリプトジャッキングで閲覧者に無断で暗号通貨を採掘させる手口も有効と考えられるので、https化すべきというのもその通り。
ただ、https化すると証明書の更新やプロトコルの危殆化に伴う対応など、維持管理の手間が増える。一部の環境ではアクセスできなくなるだろう。コストやリスクが割に合うかどうかは疑問。
Re: (スコア:0)
でも、今となってはLetsEncryptで誰でも無料で簡単にhttps化できるわけだから、
httpで放置しとく必要もないと思うけどね。
ウェブディベロッパーとして無能扱いされかねない。
Re: (スコア:0)
阿部寛のサイト管理者って、ファンサイトを公式に昇格させてるし、Web開発者にはその高速性が話題になるし、
無能扱いする奴はいなんじゃないかな。
もしhttps化してレスポンスが1%悪化したら、それを検知して無能呼ばわりしてくる奴はいるかもしれんけど。
Re: (スコア:0)
誰でも簡単httpsの先には、普通に偽サイト/詐欺サイトも https化するだけの話で、ほんと意味あるのかな？と思ってしまう
Re: (スコア:0)
今すでにもう「httpsだから本物」という認識はまずいと思うよ。
ちゃんとドメインを確認しろ、というのは今も昔も変わらない。
鍵あるなしを確認するならドメインまで確認してほしい。
今の風潮におけるhttpsの目的は通信経路の暗号化が最大の目的になってる感じだし。
EVもその価値が大幅に低下した。
Re: (スコア:0)
偽サイトが作られてユーザーがその情報に騙される可能性があることを鑑みたらHTTPS化すべき
HTTP/2やHTTP/3による速度向上も見込める
Re: (スコア:0)
HTTPSにしたところで偽サイトが作られること（フィッシングサイト）は防げない。
HTTPSで防げるのは通信経路途中のコンテンツ改竄や盗聴だけ。
// この手の間違いよくあるけど、どこ由来なんだろうか
Re: (スコア:0)
じゃあEVSSL証明書ってなんのためにあるの？
Re: (スコア:0)
SSL業者が客によって値段を変えるだけのためにあるよ。
Re: (スコア:0)
極論すれば無意味。だからEVSSL証明書不要論まである。
でも証明書を売ってるセキュリティ企業は（それが飯のタネなので）口が裂けてもそんな提言できない。
Re: (スコア:0)
実効性なんてどうでもいいんですよ。自分たちがセキュリティに気を使っている会社で、自分たちのプロダクトがセキュアだと素人に信じこませることができればいいんです。
Re: (スコア:0)
正にその通り。ただ、Googleの天才様たちがそうした正論を認識していないはずがなく、確信犯な気がするのだが、どうだろうか。
A. 社内に暗号化接続推進派の急先鋒がいる
B. 画像改竄などによる被害が多数出ている
C. 暗号化接続を禁止、検閲する国への牽制
D. 次世代プロトコルで優位に立つための仕込み
E. 混在コンテンツな競合他社サービスを潰すため
Re: (スコア:0)
確信犯警察です
この用途であれば確信犯ではなく故意犯を使うべきです
Re: (スコア:0)
>比較的危険性が低いと考えられる画像や音声、動画
これを前提としたいがために、おかしな事になってると思う。
Re: (スコア:0)
今のセキュリティの時流なら
Not Secure表示でhttpだけとか、混在が出ることについても、それなりに理解されると思う。
# コンテンツの必要性からくる安全性というよりは、情報流通としての信頼できるEnd到達性の問題が重要かなあ
# == httpとかで偽が検証できないこと、くらいの意味で
Re: (スコア:0)
現状でもGoogle Chromeは https://srad.jp/ [srad.jp] [srad.jp] にアクセスしても、アドレスバーには 「srad.jp」としか表示されず（「https://」は省略される）、http なのか https なのかはクリックしないと分からないようになっている。
え？httpの時は「保護されていない通信」って出るでしょ？クリックしたらhttpだったなんてことある？
Re: (スコア:0)
「保護されていない通信」は、http か https かを識別するためのものではなく、http でなくても証明書や暗号強度などに問題のある https でも出る。
無論、http ならば必ず「保護されていない通信」になるけどね。