今後のFirefoxの新機能は原則としてHTTPSでのみで利用可能に 35
ストーリー by hylom
脱平文 部門より
脱平文 部門より
Firefoxの一部の機能は「Secure contexts」と呼ばれるHTTPS/TLSで保護された環境でのみ利用できるようになっているが、今後実装される新機能は原則としてSecure contextsでのみ利用でき、非HTTPS/TLS環境では利用できないようにする方針をMozillaが明らかにした（Publickey）。
これには開発関連機能も含まれているという。ただし、ほかのブラウザがすでに非セキュアな環境でも提供している機能や、Secure contextsを必須にすると実装が過度に複雑になるような機能については例外となるという。また、現在非セキュアな環境で提供されている機能についても、今後Secure contextsでのみ有効になるよう変更される可能性もあるという。
新機能って何だ？ (スコア:2)
Webに関する（Web-exposed）すべての新機能は、安全なコンテキストのみに制限される。
Webに関するすべての機能とは、WebページやWebサーバで見られるJavScriptやCSSやHTTPやメディアフォーマットなどだ。
「Webに関するすべての機能」は説明してもらった。
「Webに関するすべての 新 機能」とはどういうやつなんだろうか。
特定機能の実現有無で暗号化通信下か否かを判定できてしまう？ (スコア:1, すばらしい洞察)
俺のプログラマ脳が何か嫌な予感を告げているんだけど……
うーん、職業病かな
Re: (スコア:0)
元々スキーマで判るよね…
Re: (スコア:0)
location.protocolで簡単に判別できます
Re:特定機能の実現有無で暗号化通信下か否かを判定できてしまう？ (スコア:2)
そうなんだよね。
だから、location.protocolを取得できない（あるいは取得できるけどその値を信頼できない）、かつHTTPSかどうかがわかるとうれしい状況があるかを考えてるんだけど……
#これが杞憂と言うやつか。理解した。
##杞の人は天が落ちたらどうしようと心配していたのではない。天が落ちうる状況を見逃していないかを心配していたのだ。
Re: (スコア:0)
誰がその判定を行うの？
毎度警告出してオオカミ少年認定されるよりは良い方針なんじゃないかな (スコア:1)
ページ内キャッシュ警告とかウンザリ
HTTPSを「借りる」のはやめよう。 (スコア:1)
Cloudflareを使って、無料でSSLサイトを作ってる人大勢いるけど
提供元とCloudflare間の暗号はなしで、なおかつCloudflareがMITMの仲介人になっている
そういった現状を理解してる人は少ないと思う。
ユーザーと提供元（運営サーバー）間の通信が完全に暗号化されていて、誰も読めないという保証がHTTPS鍵アイコンなのに。
この検出アドイン [mozilla.org]を入れて数日使ってるけど、オレオレHTTPSの多さに驚くよ。
Re:HTTPSを「借りる」のはやめよう。 (スコア:5, 参考になる)
錠アイコンで保証されているのは、ユーザーとフロントエンドのWebサーバ（リバースプロキシを含む）までです。CloudFlare はリバースプロキシなので、ユーザーと CloudFlare の間の暗号化が保証されているだけです。
CloudFlare に限らず、サイトによってはバックエンドのWebサーバと平文で通信しているかもしれないし、データベースサーバと個人情報をインターネット経由で平文で通信しているかもしれないし、担当者に平文でメール送信しているかもしれません。そこらへんの安全性は HTTPS ではもともと保証されていません。
そのアドオンの説明をざっと読みましたが、デフォルトでは単に CloudFlare を使っているサイトを検出しているだけみたいです。設定変更で、他のMiTMサービス（CloudFlare のようなリバースプロキシのこと？）もブロックできるようです。
CloudFlare は、HTTPS の使用についてサイト管理者が「Flexible SSL」「Full SSL」「Full SSL (Strict)」の3通りから選択することができ、「Full SSL (Strict)」では「提供元とCloudflare間の暗号はなし」ではなく HTTPS で暗号化されます（What do the SSL options mean? [cloudflare.com]）。ただし、CloudFlare が一度復号してから再度暗号化しているので、CloudFlare が通信内容を知ることができることには変わりありません。
有料プランでは CloudFlare に証明書を持ち込む（秘密鍵を預ける）こともできるようなので、企業名が表示される EV 証明書でも CloudFlare で MiTMされている可能性があると思われます。
そのアドオンの説明文では「CloudFlare は諜報機関のようなもので HTTPS の通信を復号しているから MiTM をしていて諜報機関のようなものであって、DDoS 対策のためにこういう巨大な中央集権的な企業を使わなければならないインターネットには重大な欠陥がある」と主張しており、「提供元とCloudflare間の暗号」の有無より、CloudFlare の運営者（やそこから情報を入手できる諜報機関）が HTTPS の通信の内容を知ることができることを問題視しているようです。
Re: (スコア:0)
そんなもんコロケーションの管理者なら目の前にあるハードから秘密鍵引っこ抜くことも可能だし、CAの関係者も疑えば疑えるわな。
何かやらかしたエビデンスがあるなら兎も角、特定の商用CDNだけを危険視する理由はあるんだろうか。
Re: (スコア:0)
「CloudFlare はリバースプロキシなので、ユーザーと CloudFlare の間の暗号化が保証」
確かにそうだけど、パッと見てCloudflareが挟まってるかどうかなんて
開発コンソール開いてみるか、元コメのアドオンを使うか、ファイアウォールのログでも見ない限りわからないよね。
暗号化通信やってるように見せかけて、実はCloudflareが読んでいた ←これだと暗号化の意味がない気がするんだけど。
まぁ俺のサイトはLetsEncryptをつかってて、Cloudflare噛ましてないから別にいいけど。
Re: (スコア:0)
Cloudflareが間に挟まってるとまずいの？
Cloudflareが信頼できない会社だというソースは？
間に入ってるのがやばい！とか言い始めたらISPだってやばくなっちゃうじゃん。
Re: (スコア:0)
間に入ってるのがやばい！とか言い始めたらISPだってやばくなっちゃうじゃん。
ISPのオレオレ証明書を使ってプロキシ通してない限りはISPはヤバくないと思う。
少なくとも「どこに通信しているか」は見えても「何を通信しているか」は見えない。
Cloudflareが間に挟まってるとまずいの？
Cloudflareが信頼できない会社だというソースは？
これはソース提示されてないよね。
というか、むしろ疑うならブラウザの開発元じゃね？
或いは怪しげなプラグインの開発元とかね。
ぶっちゃけ、CloudFlareよりCloudFlare検出プラグインの開発元のほう
Re:HTTPSを「借りる」のはやめよう。 (スコア:2)
その理屈だとAWS EC2とかのクラウドサーバも全部ダメになってかなり厳しくないですかね
私は私の個人サイトに自宅サーバとnginxを使ってサイトのHTTPSを解決してるのでかなり盗聴体制は高いですが
そもそも自前のサーバ使ってる人がもはや少ないのでは
Re: (スコア:0)
> その理屈だとAWS EC2とかのクラウドサーバも全部ダメになって
ちょっと読み違えてない？以下の違いを言ってると思うけど。
１）
ブラウザ －－－－－－－－－「AWS EC2施設ーーーAWSサーバー郡」
２）
ブラウザ－－－－Cloudflare－－－－「自前サーバー または AWS」
３）
ブラウザ －－－－－－－－－「私の個人サイト」
問題なのは２であって、１や３の話は誰もしてないよ。
１については、AWSが最終ゴール。その中でHTTPSからHTTPになってようが、施設内だから関係ない。
イントラも？ (スコア:0)
イントラでもhttps使えというの?
Re: (スコア:0)
ルート証明書をインストールすればいいやん
Re: (スコア:0)
イントラネット証明機関を作った方がいいぞ
Re: (スコア:0)
動かすだけなら適当なドメインを取ってワイルドカード証明書を取得してつかいまわせば良い。
Re: (スコア:0)
高いんやけど…
Let's Encrypt はイントラだとつかえないんやけども…
なんか安い所しりませんか
Re:イントラも？ (スコア:3, 参考になる)
Let's Encrypt も、今年1月からワイルドカード証明書を発行開始するそうです。ベースドメインを認証するだけでサブドメインが使えるみたいなので、
・ベースドメインは外向きサーバとして運用、Let's Encrypt で証明書を取得・更新
・↑で取得した証明書をコピーして、サブドメインでイントラサーバを運用
すれいばいいんじゃないですかね。
Re: (スコア:0)
おっ、できるようになるんか
マジ感謝
Re: (スコア:0)
ルーターの設定画面すら入れなくなる？
Re: (スコア:0)
Let's Encrypt で Manual プラグインを使うとか、 Namecheap で安い証明書を買うとかして
nginx 等ででリバースプロキシを立てれば良いと思います。
パソコン ====https===> リバースプロキシサーバー ---http---> ルーター
Re: (スコア:0)
そこまでするぐらいなら「firefoxを捨てる」ほうが現実的な気がする
やめてほしい (スコア:0)
暗号化は本来、セキュリティを確保するための手段であって、目的ではない筈なのだが。
中途半端に「暗号化してないサイトでは使えない機能」みたいなのを増やしていくと、暗号化を手段ではなく目的としてしまうWebサイト管理者が出てくるのが目に見えてるんだよなぁ。
最近やっと公的機関のオレオレ証明書とかが淘汰されてきたのに、それに似た問題が再発しないかが心配。
Verisign「が」やらかした、あるいはVerisign「ですら」やらかしたような現状で、もっと質の悪いCAが出てくる原因になるんじゃないだろうか、という懸念は、考えすぎだろうか。
Re: (スコア:0)
HTTPSのデジタル証明書で相手がどこの誰かが確定した上で、
さてどうするかが問題なわけです。
HTTPS化はセキュリティ確保の手段ですらなく、単なる前提条件に過ぎません。
Re: (スコア:0)
じゃあ前提条件が目的になっちまう可能性があるというか、勘違いする○○が今後沢山でてくるかもってことか。
もっとひどいじゃないですかやだー。
Re: (スコア:0)
バカにつけるクスリはないってこったな
CSSをセキュア環境のみに制限する意図がわからない (スコア:0)
セキュア環境のみに提供する新機能として今後実装されるCSSのプロパティも含まれるようだけど，
その意図がわからないし強引過ぎない？
CSSは文章やアプリの見た目を設定する役割りのスタティックなプロパティなので，
それ自体に深刻な権限はないと思うんだけど．
もちろんJSなんかと組み合わせるといろいろできちゃいそうだけど，
それならJSをセキュア環境に限定するなりクロスドメインでのJS利用を制限すればいいのでは？
ローカルのヘルプや簡単なドキュメントをHTMLで提供しているソフトウェアも多いけど，
それらでもこの先追加されるCSSが利用できなくなるとか不便になると思う．
(この先追加されるCSS color keywordみたいなものは制限しないようですが)
それともCSSでもセキュアにしないと危険なものが今後予定されてるのかな．
それってもはやCSSの役割りを超えてない？
Re:CSSをセキュア環境のみに制限する意図がわからない (スコア:2, 興味深い)
将来のことについてはわからないし直接関係しないとは思うけど
下記のCSSに関する記事を読んで驚いたので紹介してみる。
CSSのこのアイデアはすごすぎる！Webページのトラッキング・解析ができるスタイルシート -Crooked Style Sheets [coliss.com]
Re: (スコア:0)
ご紹介ありがとうございます．
主に url() 関数を利用するテクニックのようですね．
こういった利用のされかたの懸念は，
url() 関数の呼び出し元／先を https または同一ドメインに制限するだけはダメなんですかね．
(その制限下でもそこまでしてやりたければどうぞ，という感じですが．)
Re: (スコア:0)
フィッシングはやばいでしょ。画像は丸々引っ張って来れるし、リンクのターゲットはpointer-eventsで無効化できるし。電話番号とか書けるんだから。
CSSの機能が制限されてるのはコンテンツとスタイルを分離させる思想から来てるだけで、セキュリティとは何の関係もないし、乗っ取られたらマズいことに変わりはない。
Re: (スコア:0)
CSSの機能が制限されてるのはコンテンツとスタイルを分離させる思想から来てるだけで、セキュリティとは何の関係もないし、乗っ取られたらマズいことに変わりはない。
そのコンテンツとスタイルを分離する思想で，純粋なスタイルの役割には本来セキュリティを脅かすようなものではなかったが，
検討が不十分なまま高機能化するにつれてセキュリティに影響するものが含まれてきているのではないでしょうか．
例にあげられている pointer-events のようなものとか．
フィッシングはスタティックな CSS の改竄だけで可能でしょうか (動的に生成する CSS は別として)．
簡単なものはともかく高度なフィッシングだと前提として HTML や JS の改竄が必要になりそうですけど，
そうなるともうお手上げの状態だと思います．
懸念しているのは，
影響範囲を検討・切り分けせずに一律的に制限して開発者への負担を省みない Mozilla の姿勢です．
CoinCheckの問題 (スコア:0)
その通りなわけで あまり過信しないことを勧める SSL系通信