パスワードを忘れた? アカウント作成
13509465 story
Firefox

今後のFirefoxの新機能は原則としてHTTPSでのみで利用可能に 35

ストーリー by hylom
脱平文 部門より

Firefoxの一部の機能は「Secure contexts」と呼ばれるHTTPS/TLSで保護された環境でのみ利用できるようになっているが、今後実装される新機能は原則としてSecure contextsでのみ利用でき、非HTTPS/TLS環境では利用できないようにする方針をMozillaが明らかにした(Publickey)。

これには開発関連機能も含まれているという。ただし、ほかのブラウザがすでに非セキュアな環境でも提供している機能や、Secure contextsを必須にすると実装が過度に複雑になるような機能については例外となるという。また、現在非セキュアな環境で提供されている機能についても、今後Secure contextsでのみ有効になるよう変更される可能性もあるという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by st1100 (45287) on 2018年01月25日 0時14分 (#3350293)

    Webに関する(Web-exposed)すべての新機能は、安全なコンテキストのみに制限される。

    Webに関するすべての機能とは、WebページやWebサーバで見られるJavScriptやCSSやHTTPやメディアフォーマットなどだ。

    「Webに関するすべての機能」は説明してもらった。
    「Webに関するすべての 新 機能」とはどういうやつなんだろうか。

  • 俺のプログラマ脳が何か嫌な予感を告げているんだけど……
    うーん、職業病かな

  • ページ内キャッシュ警告とかウンザリ

  • by Anonymous Coward on 2018年01月23日 22時49分 (#3349692)

    Cloudflareを使って、無料でSSLサイトを作ってる人大勢いるけど
    提供元とCloudflare間の暗号はなしで、なおかつCloudflareがMITMの仲介人になっている
    そういった現状を理解してる人は少ないと思う。

    ユーザーと提供元(運営サーバー)間の通信が完全に暗号化されていて、誰も読めないという保証がHTTPS鍵アイコンなのに。

    この検出アドイン [mozilla.org]を入れて数日使ってるけど、オレオレHTTPSの多さに驚くよ。

    • ユーザーと提供元(運営サーバー)間の通信が完全に暗号化されていて、誰も読めないという保証がHTTPS鍵アイコンなのに。

      錠アイコンで保証されているのは、ユーザーとフロントエンドのWebサーバ(リバースプロキシを含む)までです。CloudFlare はリバースプロキシなので、ユーザーと CloudFlare の間の暗号化が保証されているだけです。

      CloudFlare に限らず、サイトによってはバックエンドのWebサーバと平文で通信しているかもしれないし、データベースサーバと個人情報をインターネット経由で平文で通信しているかもしれないし、担当者に平文でメール送信しているかもしれません。そこらへんの安全性は HTTPS ではもともと保証されていません。

      この検出アドイン [mozilla.org]を入れて数日使ってるけど、オレオレ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 の通信の内容を知ることができることを問題視しているようです。

      親コメント
      • by Anonymous Coward

        そんなもんコロケーションの管理者なら目の前にあるハードから秘密鍵引っこ抜くことも可能だし、CAの関係者も疑えば疑えるわな。
        何かやらかしたエビデンスがあるなら兎も角、特定の商用CDNだけを危険視する理由はあるんだろうか。

      • by Anonymous Coward

        「CloudFlare はリバースプロキシなので、ユーザーと CloudFlare の間の暗号化が保証」

        確かにそうだけど、パッと見てCloudflareが挟まってるかどうかなんて
        開発コンソール開いてみるか、元コメのアドオンを使うか、ファイアウォールのログでも見ない限りわからないよね。

        暗号化通信やってるように見せかけて、実はCloudflareが読んでいた ←これだと暗号化の意味がない気がするんだけど。

        まぁ俺のサイトはLetsEncryptをつかってて、Cloudflare噛ましてないから別にいいけど。

        • by Anonymous Coward

          Cloudflareが間に挟まってるとまずいの?
          Cloudflareが信頼できない会社だというソースは?

          間に入ってるのがやばい!とか言い始めたらISPだってやばくなっちゃうじゃん。

          • by Anonymous Coward

            間に入ってるのがやばい!とか言い始めたらISPだってやばくなっちゃうじゃん。

            ISPのオレオレ証明書を使ってプロキシ通してない限りはISPはヤバくないと思う。
            少なくとも「どこに通信しているか」は見えても「何を通信しているか」は見えない。

            Cloudflareが間に挟まってるとまずいの?
            Cloudflareが信頼できない会社だというソースは?

            これはソース提示されてないよね。

            というか、むしろ疑うならブラウザの開発元じゃね?
            或いは怪しげなプラグインの開発元とかね。

            ぶっちゃけ、CloudFlareよりCloudFlare検出プラグインの開発元のほう

    • その理屈だとAWS EC2とかのクラウドサーバも全部ダメになってかなり厳しくないですかね
      私は私の個人サイトに自宅サーバとnginxを使ってサイトのHTTPSを解決してるのでかなり盗聴体制は高いですが
      そもそも自前のサーバ使ってる人がもはや少ないのでは

      親コメント
      • by Anonymous Coward

        > その理屈だとAWS EC2とかのクラウドサーバも全部ダメになって
        ちょっと読み違えてない?以下の違いを言ってると思うけど。

        1)
        ブラウザ ---------「AWS EC2施設ーーーAWSサーバー郡」

        2)
        ブラウザ----Cloudflare----「自前サーバー または AWS」

        3)
        ブラウザ ---------「私の個人サイト」

        問題なのは2であって、1や3の話は誰もしてないよ。
        1については、AWSが最終ゴール。その中でHTTPSからHTTPになってようが、施設内だから関係ない。

  • by Anonymous Coward on 2018年01月23日 18時39分 (#3349520)

    イントラでもhttps使えというの?

    • by Anonymous Coward

      ルート証明書をインストールすればいいやん

    • by Anonymous Coward

      イントラネット証明機関を作った方がいいぞ

    • by Anonymous Coward

      動かすだけなら適当なドメインを取ってワイルドカード証明書を取得してつかいまわせば良い。

      • by Anonymous Coward

        高いんやけど…
        Let's Encrypt はイントラだとつかえないんやけども…

        なんか安い所しりませんか

        • Re:イントラも? (スコア:3, 参考になる)

          by taka2 (14791) on 2018年01月24日 11時39分 (#3349903) ホームページ 日記

          Let's Encrypt も、今年1月からワイルドカード証明書を発行開始するそうです。ベースドメインを認証するだけでサブドメインが使えるみたいなので、

          ・ベースドメインは外向きサーバとして運用、Let's Encrypt で証明書を取得・更新
          ・↑で取得した証明書をコピーして、サブドメインでイントラサーバを運用

          すれいばいいんじゃないですかね。

          親コメント
          • by Anonymous Coward

            おっ、できるようになるんか
            マジ感謝

    • by Anonymous Coward

      ルーターの設定画面すら入れなくなる?

      • by Anonymous Coward

        Let's Encrypt で Manual プラグインを使うとか、 Namecheap で安い証明書を買うとかして
        nginx 等ででリバースプロキシを立てれば良いと思います。

        パソコン ====https===> リバースプロキシサーバー ---http---> ルーター

        • by Anonymous Coward

          そこまでするぐらいなら「firefoxを捨てる」ほうが現実的な気がする

  • by Anonymous Coward on 2018年01月23日 22時14分 (#3349670)

    暗号化は本来、セキュリティを確保するための手段であって、目的ではない筈なのだが。

    中途半端に「暗号化してないサイトでは使えない機能」みたいなのを増やしていくと、暗号化を手段ではなく目的としてしまうWebサイト管理者が出てくるのが目に見えてるんだよなぁ。
    最近やっと公的機関のオレオレ証明書とかが淘汰されてきたのに、それに似た問題が再発しないかが心配。

    Verisign「が」やらかした、あるいはVerisign「ですら」やらかしたような現状で、もっと質の悪いCAが出てくる原因になるんじゃないだろうか、という懸念は、考えすぎだろうか。

    • by Anonymous Coward

      HTTPSのデジタル証明書で相手がどこの誰かが確定した上で、
      さてどうするかが問題なわけです。
      HTTPS化はセキュリティ確保の手段ですらなく、単なる前提条件に過ぎません。

      • by Anonymous Coward

        じゃあ前提条件が目的になっちまう可能性があるというか、勘違いする○○が今後沢山でてくるかもってことか。
        もっとひどいじゃないですかやだー。

        • by Anonymous Coward

          バカにつけるクスリはないってこったな

  • by Anonymous Coward on 2018年01月24日 2時27分 (#3349760)

    セキュア環境のみに提供する新機能として今後実装されるCSSのプロパティも含まれるようだけど,
    その意図がわからないし強引過ぎない?

    CSSは文章やアプリの見た目を設定する役割りのスタティックなプロパティなので,
    それ自体に深刻な権限はないと思うんだけど.

    もちろんJSなんかと組み合わせるといろいろできちゃいそうだけど,
    それならJSをセキュア環境に限定するなりクロスドメインでのJS利用を制限すればいいのでは?

    ローカルのヘルプや簡単なドキュメントをHTMLで提供しているソフトウェアも多いけど,
    それらでもこの先追加されるCSSが利用できなくなるとか不便になると思う.
    (この先追加されるCSS color keywordみたいなものは制限しないようですが)

    それともCSSでもセキュアにしないと危険なものが今後予定されてるのかな.
    それってもはやCSSの役割りを超えてない?

    • by Anonymous Coward on 2018年01月24日 2時56分 (#3349765)

      将来のことについてはわからないし直接関係しないとは思うけど
      下記のCSSに関する記事を読んで驚いたので紹介してみる。

      CSSのこのアイデアはすごすぎる!Webページのトラッキング・解析ができるスタイルシート -Crooked Style Sheets [coliss.com]

      親コメント
      • by Anonymous Coward

        ご紹介ありがとうございます.
        主に url() 関数を利用するテクニックのようですね.

        こういった利用のされかたの懸念は,
        url() 関数の呼び出し元/先を https または同一ドメインに制限するだけはダメなんですかね.
        (その制限下でもそこまでしてやりたければどうぞ,という感じですが.)

    • by Anonymous Coward

      フィッシングはやばいでしょ。画像は丸々引っ張って来れるし、リンクのターゲットはpointer-eventsで無効化できるし。電話番号とか書けるんだから。

      CSSの機能が制限されてるのはコンテンツとスタイルを分離させる思想から来てるだけで、セキュリティとは何の関係もないし、乗っ取られたらマズいことに変わりはない。

      • by Anonymous Coward

        CSSの機能が制限されてるのはコンテンツとスタイルを分離させる思想から来てるだけで、セキュリティとは何の関係もないし、乗っ取られたらマズいことに変わりはない。

        そのコンテンツとスタイルを分離する思想で,純粋なスタイルの役割には本来セキュリティを脅かすようなものではなかったが,
        検討が不十分なまま高機能化するにつれてセキュリティに影響するものが含まれてきているのではないでしょうか.
        例にあげられている pointer-events のようなものとか.

        フィッシングはスタティックな CSS の改竄だけで可能でしょうか (動的に生成する CSS は別として).
        簡単なものはともかく高度なフィッシングだと前提として HTML や JS の改竄が必要になりそうですけど,
        そうなるともうお手上げの状態だと思います.

        懸念しているのは,
        影響範囲を検討・切り分けせずに一律的に制限して開発者への負担を省みない Mozilla の姿勢です.

  • by Anonymous Coward on 2018年01月26日 20時09分 (#3351360)

    その通りなわけで あまり過信しないことを勧める SSL系通信

typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...