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

Google、Chrome 94 以降で HTTPS 優先モードを導入する計画 54

ストーリー by headless
優先 部門より
Google は14日、Chrome 94 以降で HTTPS 優先モード(HTTPS-First Mode)を利用可能にする計画を発表した(Chromium Blog の記事The Verge の記事SlashGear の記事)。

Chrome では現在、Omnibox にプロトコルを省略した URL を入力した場合に HTTPS 接続を優先して接続するようになっているが、HTTP プロトコルを指定した場合にはサイト側でリダイレクトされない限り HTTP 接続となる。HTTPS 優先モードは HTTP プロトコルを指定した場合でもまず HTTPS で接続し、対応していない場合は HTTP でページを表示する前に全画面で警告を表示するという。

同様のオプションは既にFirefox が搭載しており、Microsoft Edge もプレビュー版(Beta/Dev/Canary)でedge:flagsのAutomatic HTTPS (edge://flags/#edge-automatic-https")を Enabled にすることでオプションが利用可能になる。Google では Chrome 94 以降でテストを行い、デフォルトで有効にするかどうかを決めるとのこと。

また、Chrome 93 では HTTPS 接続時の南京錠のアイコン表示をやめ、ドロップダウンボタンのようなニュートラルな表示に置き換える実験をするそうだ。これは南京錠のアイコンが通信の暗号化を示すだけなのにもかかわらず、サイトが信頼可能であるような印象を与えてしまいことを避けるためだという。その一方で、HTTP 接続時の「保護されていない通信」という表示は維持していくとのことだ。
  • by Anonymous Coward on 2021年07月18日 10時05分 (#4073428)

    別にプロトコル省略時の実装と同じタイミングで実装しておけば良かったじゃん。
    逆にこの実装にデメリットなんてあるの?

    ここに返信
    • サブジェクトとか、本文とか! 寝てる間にゴキブリに持っていかれた?

    • by Anonymous Coward

      LAN内にウェブサーバを置いておくのに面倒が生じる。
      NASとかルータの管理画面とかどうするのかな。

      無料のTLS証明書ってグローバルなDNSで名前引いて外からアクセス出来るようなものに対してしか発行できないし。
      かと言って、その手の設定ページを外から見えるURLに紐付けるのは、設定をミスしたときに要らない弱点ができることになって良くないし。

      ああ、さすがにそれぐらいは考えられてて、同一LAN内のアドレスに対しては最初から素直にhttpで繋いでくれるのかな。

      • by Anonymous Coward

        「今後は警告メッセージを表示しない」にチェックを入れるだけでは?

        • by Anonymous Coward

          自宅ならそれでいいが、会社だとサーバの数が多いと面倒なんだよな。
          最近だと証明書をインストールさせてくれるBMC系ユニット増えたけど。

          • by Anonymous Coward

            会社ならローカルネットワークのサーバー用にワイルドカード証明書でも作っておけば?

            • by Anonymous Coward

              やろうとしたけど、安全側に倒す維持コストが難しくてあきらめたわ
              何らかの事情でもれた時がしゃれになってないので

      • by Anonymous Coward

        NASとかは、その証明書をローカルPCのルート証明書に追加しておけばいいだけでないの?

      • by Anonymous Coward

        FirefoxのHTTPSモードの場合はLAN内のアドレスに対してもHTTPSで繋ごうとして親切な警告出してくれますね
        危険を承知でHTTPで接続するボタンを押すだけですが

      • by Anonymous Coward

        LANなら自分らのCA証明書くらい配布して管理しろよ。
        つかLANだからhttpでいいってどういう了見してんだよ。

        • by Anonymous Coward

          専用線全否定かな?

        • by Anonymous Coward

          自宅のLANに侵入される可能性で、そこまでやった方がいい話ってあるかな。

          まずは定番のウィルスだけど、httpsサーバとクライアントを動かす機械にウィルスをインストールしてしまった場合は効き目がない。
          それ以外の機械にウィルスを入れてしまった場合でも盗聴を防げる、というようには効くけど。

          無線LANはそこそこのパスフレーズにしておけばだいたい大丈夫。
          あと、物理的に侵入されてハブに何かを仕込まれる可能性について真剣に考えなきゃならない生活はLANを気にしてる場合じゃない。

          証明書を適切に管理できてないと危険が増すわけで、きちんと徹底管理しなきゃならない事を考えると、かける手間分のリターンが得られるとは思えない。

          もうちょっと人の出入りが多い会社のオフィスぐらいだったら暗号化必須だろうけど。

          • by Anonymous Coward

            自宅なら今後表示しないにチェック入れるだけだし、会社みたいな多人数の拠点ならLANだからhttpでいいというのがセキュリティガバガバなので、その主張はおかしい。

  • by Anonymous Coward on 2021年07月18日 10時30分 (#4073433)

    URLとして「example.com」と入力してエンター押すと、「www.example.com」を開こうとする。
    example.comに接続したかったら「http://example.com」と入力しないといけない。
    example.com優先でアクセスできなかったらwwwに誘導してもらいたい。

    ここに返信
    • by Anonymous Coward

      >URLとして「example.com」と入力してエンター押すと、「www.example.com」を開こうとする。
      試したけどならないよ?
      サイト側の設定如何でしょ。

      • by Anonymous Coward

        いや、それはおそらくブラウザの機能ですよ。上のコメントを試そうとした場合、"example.com"が例として良くないだけだと思う。みんなが誤用し続けるから、exampleさんが怒っちゃってこうなってるわけで。

        それはともかく、例えばFirefoxは、"hogehogepiyopiyo"って打つと、"https://hogehogepiyopiyo.com"に補完して、それがダメなら"https://www.hogehogepiyopiyo.com"にアクセスする機能があります。

        ただし、通常状態だと「"hogehogepiyopiyo"の検索結果」の方が強いので、その機能を切ってる時じゃないと実感できないでしょうけれど、"hogehogepiyopiyo.com"の場合は検索より強いので、まず"https://hogehogepiyopiyo.com"に修正して、そのあと"https://www.hogehogepiyopiyo.com"になります。

        about:configで、"fixup"とタイプすれば、いろいろ設定を変えられます。

        • by Anonymous Coward

          #4073438 ではないが、

          元コメは、example.comを入力するとexample.comではなくwww.example.comを開く機能がブラウザにあると言っていて、
          #4073438はそんな事は無く単純にexample.comが開かれていると言っているだけだよ。
          開発者ツールで見てもそうなってるはず。
          www.を補完するプロセスは色々だけど、基本はサーバー主導だと思う。

          ただ元コメの言う事も少し気になっていて、過去の閲覧かリダイレクト履歴かなんかで、直接www.付きを開く挙動があるかもしんない。

        • by Anonymous Coward

          >"https://hogehogepiyopiyo.com"に補完して、それがダメなら"https://www.hogehogepiyopiyo.com"にアクセスする機能があります。
          元コメは、「wwwを優先して」と言っているわけだが。順番違うでしょ。

          • by Anonymous Coward

            それは補完の時に"http"を試さなくて全部httpsにしてるからで、wwwが優先されてるわけじゃないと思う。

  • いまでも、HTTPSでアクセスすると、期限切れ証明書が入ってたり、クラウド提供者のドメインの証明書が入ってたり、
    そんなサイトは多い

    そういったサイトに勝手にHTTPSでつながると不正な証明書とされてアクセスできなくなる

    ここに返信
  • by Anonymous Coward on 2021年07月18日 11時20分 (#4073441)

    httpsにできなくて、httpのままのときに警告画面が出るのがめんどいんだよね。
    警告画面が出ないオプションが欲しい。

    Google検索でhttpsしか引っかからないようにすればいいのに。
    次にChromeでhttpsしかアクセスできなくするのも。

    ここに返信
  • by Anonymous Coward on 2021年07月18日 11時51分 (#4073449)

    パッケージ入れたらブラウザで管理できるツールは中でイントラ用のサーバが立ち上がってるんだけど httpだけじゃなくてhttpsまでオレオレ証明書で入れてくるんで イントラならhttpがいいんだよ ウェブアプリ開発とかも同じです

    ここに返信
    • by Anonymous Coward

      どうやって、アクセスしようとしたサーバがイントラなのかパブリックなのかを判断したらいいの?
      Google 様がクロールできなかったらイントラ扱い?

      • by Anonymous Coward

        判断できないのに強行するから困っているんだよ 僕らが要望を出したわけじゃない

      • by Anonymous Coward

        IPアドレスで判断できるだろ。
        社内で43で始まるIPアドレス使ってるとかふざけてるところを除いては。

    • by Anonymous Coward

      イントラ用のオレオレルート証明書を作って、
      イントラのサーバは全部オレオレ認証局で署名、
      各PCやブラウザにはオレオレルート証明書を1つインストールしておく

      こんなのでいいよ

      • by Anonymous Coward on 2021年07月18日 15時36分 (#4073506)

        ルート証明書の権限が強するので、オレオレルート証明書を入れるとかえって危険になるんだよね。
        イントラアクセスするときには毎回ブラウザのセキュリティ警告無視した方がマシなレベル。

        仮にオレオレ認証局のルート証明書の秘密鍵が漏洩したとする。
        (インサイダーがHDD/SSDを直接読み取って鍵を盗んでも漏洩する)
        そしてLAN内に悪意のあるホストが1台紛れさせて、そのホストはMACアドレスを詐称してルータに成り済ます。
        でプレインストールアプリ等の https://.autoupdate.example.com/ [example.com] の通信を乗っ取って悪意のあるファイルを実行させることも可能。

        OSプレインストールの既存の大手認証局と同レベルの管理ができないならばオレオレルート証明書をLAN内の端末にインストールする運用は止めた方がいい。
        その認証局の秘密鍵が奪われたとき、LAN内のオレオレ証明書入れたマシンが一気に乗っ取られてしまう。

        • by Anonymous Coward

          一応、オレオレ認証局が勝手によそ様のドメインの証明書を発行することへの緩和策はいろいろある。が、ウェブブラウザ以外のクライアントの対応があまり期待できない状況だと思う。

          • オレオレ認証局を作る側:証明書のName Constraintsで許可するドメイン名を指定しておく。
          • インターネット上でHTTPSウェブサイトを公開する側:DNS CAAで自ドメインの証明書の発行を許可する認証局を指定しておく。
          • 〃:証明書をCertificate Transparencyログに登録しておく(大抵のパブリックな認証局は証明書発行時にやってくれるので、現在特別な作業は不要)。
          • by Anonymous Coward

            自己レス、DNSのCAAはオレオレ認証局対策にはならないな。すまん。

  • by Anonymous Coward on 2021年07月18日 13時47分 (#4073480)

    今どきフィッシングサイトもhttpsだし、DV証明書は相手の存在を全く保証しないので「安全の担保」には程遠い。
    あと企業NWみたいな所ではhttpsだろうが傍受されて中身は覗かれてるし、httpsの「経路は安全」ってのもかなり嘘。
    唯一httpsが有効に機能してる例は、悪意のある野良wi-fi経由で傍受されても大丈夫って所だけ。

    httpを過度に危険視することで「httpsは安全」という誤解を招いてる方が有害だと思う。

    ここに返信
    • by Anonymous Coward on 2021年07月18日 14時18分 (#4073488)

      今までhttpsを「特別扱い」してきたけど、今後は「それが普通」にしようということ。

    • by Anonymous Coward

      安全策には必ずこういうアレルギー反応出るけどまあ恒例。

      ノーヘルを過度に危険視する事でヘルメットしてれば運転は安全という誤解を…

      みたいなもんだね。平文通信はありえない、これが最低限でしょ。

      • by Anonymous Coward

        安全策には必ずこういうアレルギー反応出るけどまあ恒例。

        ノーヘルを過度に危険視する事でヘルメットしてれば運転は安全という誤解を…

        みたいなもんだね。平文通信はありえない、これが最低限でしょ。

        インターネットの特性上、むしろ「平文でも構わない」って通信の方が多いよ。
        一方で「絶対に傍受されては困る」通信もある。
        その間ってものはない。

        ブラウザが実装すべきなのは「平文でも構わないものを強制暗号化」するより
        「傍受されている可能性」を検出して警告出すことだと思うよ。

        • by Anonymous Coward

          平文通信は、その「傍受されている可能性」が高いから警告出してるんでしょうに。

          • by Anonymous Coward

            だったら傍受されてるSSLも警告出さないといけない。
            片手落ちなんだよ。

            • by Anonymous Coward

              少なくとも検出可能な傍受の可能性をまず警告することに問題はないでしょ。
              両手落ちてるよりは、片手だけでも凌ぐべき。
              傍受されるSSLの検出は困難な場合が多い。(傍受自体も困難だけれども)

              • by Anonymous Coward

                傍受されてるSSLの検出って技術的にはそれほど困難ではなくて、自己署名証明書がサイト証明書に使われてると100%ビンゴ。
                あと「ブラウザ開発元が信用したルート証明書以外」では、全て何らかの警告を出すこと(○○組織によって署名されています等)でも対応できる。
                傍受を検出したら強制終了させるサイトもあるよね。そういうところはデコード除外設定するしかないってのをNW運用してれば経験するはず。

                現実問題として傍受されてるSSLって100%ロギングされてるので、傍受されてるかされていないか不明なHTTP通信以上に危険な存在だよ。
                なので片手落ちって話。より危険なものを認知できる手段を用意しないのに、それよりは低い危険性をさも「最も危険な通信」みたいに煽るなと。

              • by Anonymous Coward on 2021年07月19日 1時13分 (#4073716)

                傍受検出で強制終了ではないけど、怪しい証明書を見かけたら報告するぞって仕組みは始まろうとしている。

                Opt-out SCT Auditing in Chrome [google.com]

                ただ、ウェブブラウザの証明書関係の機能、チェーンを辿るとプライベートなルート認証局だった場合はだいたい適用除外になる印象だよね。その点あまり期待できない。

              • by Anonymous Coward

                そんな簡単なものは検出と言うまでもないでしょ。
                難しいのは、正規のルート証明書を不正利用されたもので、過去にも何度か問題が起きている。

              • by Anonymous Coward

                それは次元の違う問題。DVもEVも見分けることが困難になった現在は些細な問題。

                あと正規ルートの証明書は傍受には使えない。
                傍受製品はオレオレ証明書を動的作成したりTLDが*とか絶対に正規発行されない奴を使う。

        • by Anonymous Coward

          > インターネットの特性上、むしろ「平文でも構わない」って通信の方が多いよ。
          プライバシーの概念捨ててる人相手にしてるとは思わなかった。
          通信先は今の所隠蔽できないけど、最終的には全て不可視になるべきだと思うよ。

          > 一方で「絶対に傍受されては困る」通信もある。
          バイナリ思考だね。

          • by Anonymous Coward

            >プライバシーの概念捨ててる人相手にしてるとは思わなかった。

            プライバシー問題は経路上の話ではなくてcookieやトラッキングURLの問題。
            あと常時SSLの話が出てきた頃はSSLデコードが一般的ではなかったので事情が変わってる。

            • by Anonymous Coward

              「常時傍受されている」のが「傍受されてるかどうかわからない」より危険ってのは、一般の感覚ではそうだけど、ちょっとでもセキュリティを齧ればそんな意見にはならないと思う。

  • by Anonymous Coward on 2021年07月18日 15時54分 (#4073509)

    http://spring-fragrance.mints.ne.jp/aviutl/ [mints.ne.jp]
    この↑ページにアクセスしようとして、HTTPS優先モードだと、
    https://spring-fragrance.mints.ne.jp/aviutl/ [mints.ne.jp]
    Not Found と表示されてしまって困るのよね。
    FirefoxのHTTPS-Onlyモードを使ってハマってしまった…

    ここに返信
typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...