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 接続時の「保護されていない通信」という表示は維持していくとのことだ。
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 接続時の「保護されていない通信」という表示は維持していくとのことだ。
え、まだだったの？ (スコア:0)
別にプロトコル省略時の実装と同じタイミングで実装しておけば良かったじゃん。
逆にこの実装にデメリットなんてあるの？
あれれ。なにか重要なものが抜けてる気がしますよ (スコア:0)
サブジェクトとか、本文とか! 寝てる間にゴキブリに持っていかれた？
Re: (スコア:0)
LAN内にウェブサーバを置いておくのに面倒が生じる。
NASとかルータの管理画面とかどうするのかな。
無料のTLS証明書ってグローバルなDNSで名前引いて外からアクセス出来るようなものに対してしか発行できないし。
かと言って、その手の設定ページを外から見えるURLに紐付けるのは、設定をミスしたときに要らない弱点ができることになって良くないし。
ああ、さすがにそれぐらいは考えられてて、同一LAN内のアドレスに対しては最初から素直にhttpで繋いでくれるのかな。
Re: (スコア:0)
「今後は警告メッセージを表示しない」にチェックを入れるだけでは？
Re: (スコア:0)
自宅ならそれでいいが、会社だとサーバの数が多いと面倒なんだよな。
最近だと証明書をインストールさせてくれるBMC系ユニット増えたけど。
Re: (スコア:0)
会社ならローカルネットワークのサーバー用にワイルドカード証明書でも作っておけば？
Re: (スコア:0)
やろうとしたけど、安全側に倒す維持コストが難しくてあきらめたわ
何らかの事情でもれた時がしゃれになってないので
Re: (スコア:0)
NASとかは、その証明書をローカルPCのルート証明書に追加しておけばいいだけでないの？
Re: (スコア:0)
FirefoxのHTTPSモードの場合はLAN内のアドレスに対してもHTTPSで繋ごうとして親切な警告出してくれますね
危険を承知でHTTPで接続するボタンを押すだけですが
Re: (スコア:0)
LANなら自分らのCA証明書くらい配布して管理しろよ。
つかLANだからhttpでいいってどういう了見してんだよ。
Re: (スコア:0)
専用線全否定かな？
Re: (スコア:0)
自宅のLANに侵入される可能性で、そこまでやった方がいい話ってあるかな。
まずは定番のウィルスだけど、httpsサーバとクライアントを動かす機械にウィルスをインストールしてしまった場合は効き目がない。
それ以外の機械にウィルスを入れてしまった場合でも盗聴を防げる、というようには効くけど。
無線LANはそこそこのパスフレーズにしておけばだいたい大丈夫。
あと、物理的に侵入されてハブに何かを仕込まれる可能性について真剣に考えなきゃならない生活はLANを気にしてる場合じゃない。
証明書を適切に管理できてないと危険が増すわけで、きちんと徹底管理しなきゃならない事を考えると、かける手間分のリターンが得られるとは思えない。
もうちょっと人の出入りが多い会社のオフィスぐらいだったら暗号化必須だろうけど。
Re: (スコア:0)
自宅なら今後表示しないにチェック入れるだけだし、会社みたいな多人数の拠点ならLANだからhttpでいいというのがセキュリティガバガバなので、その主張はおかしい。
www優先をやめてｗww (スコア:0)
URLとして「example.com」と入力してエンター押すと、「www.example.com」を開こうとする。
example.comに接続したかったら「http://example.com」と入力しないといけない。
example.com優先でアクセスできなかったらwwwに誘導してもらいたい。
Re: (スコア:0)
＞URLとして「example.com」と入力してエンター押すと、「www.example.com」を開こうとする。
試したけどならないよ？
サイト側の設定如何でしょ。
Re: (スコア:0)
いや、それはおそらくブラウザの機能ですよ。上のコメントを試そうとした場合、"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"とタイプすれば、いろいろ設定を変えられます。
Re: (スコア:0)
#4073438 ではないが、
元コメは、example.comを入力するとexample.comではなくwww.example.comを開く機能がブラウザにあると言っていて、
#4073438はそんな事は無く単純にexample.comが開かれていると言っているだけだよ。
開発者ツールで見てもそうなってるはず。
www.を補完するプロセスは色々だけど、基本はサーバー主導だと思う。
ただ元コメの言う事も少し気になっていて、過去の閲覧かリダイレクト履歴かなんかで、直接www.付きを開く挙動があるかもしんない。
Re: (スコア:0)
＞"https://hogehogepiyopiyo.com"に補完して、それがダメなら"https://www.hogehogepiyopiyo.com"にアクセスする機能があります。
元コメは、「wwwを優先して」と言っているわけだが。順番違うでしょ。
Re: (スコア:0)
それは補完の時に"http"を試さなくて全部httpsにしてるからで、wwwが優先されてるわけじゃないと思う。
HTTPSでアクセスすると無効な証明書が入ってるサイト対策は？ (スコア:0)
いまでも、HTTPSでアクセスすると、期限切れ証明書が入ってたり、クラウド提供者のドメインの証明書が入ってたり、
そんなサイトは多い
そういったサイトに勝手にHTTPSでつながると不正な証明書とされてアクセスできなくなる
Re:HTTPSでアクセスすると無効な証明書が入ってるサイト対策は？ (スコア:1)
そういう危険なサイトを避けてもらう為の処置なんだから、そのままで良いのでは？
逆にそういうユーザーに危険なサービスを提供している事業者は、さっさとTLSに対応するか事業をたためば良い。
Re: (スコア:0)
id/pw、クレカ番号や個人情報を入力するようなサイトならわかるんだけど、
読むだけの古の個人サイトなんかは何の危険もないと思うんだが・・・
Re: (スコア:0)
> クラウド提供者のドメインの証明書が入ってたり
君が言いたいのは、クラウド証明書は中間者攻撃と同じ [nogafam.es]ということかね.
Re: (スコア:0)
「クラウド提供者が提供してくれる証明書」と「クラウド提供者のドメインの証明書」の区別ができない阿呆
Firefoxでの印象 (スコア:0)
httpsにできなくて、httpのままのときに警告画面が出るのがめんどいんだよね。
警告画面が出ないオプションが欲しい。
Google検索でhttpsしか引っかからないようにすればいいのに。
次にChromeでhttpsしかアクセスできなくするのも。
イントラではやめて (スコア:0)
パッケージ入れたらブラウザで管理できるツールは中でイントラ用のサーバが立ち上がってるんだけど httpだけじゃなくてhttpsまでオレオレ証明書で入れてくるんで イントラならhttpがいいんだよ ウェブアプリ開発とかも同じです
Re: (スコア:0)
どうやって、アクセスしようとしたサーバがイントラなのかパブリックなのかを判断したらいいの？
Google 様がクロールできなかったらイントラ扱い？
Re: (スコア:0)
判断できないのに強行するから困っているんだよ 僕らが要望を出したわけじゃない
Re: (スコア:0)
IPアドレスで判断できるだろ。
社内で43で始まるIPアドレス使ってるとかふざけてるところを除いては。
Re: (スコア:0)
イントラ用のオレオレルート証明書を作って、
イントラのサーバは全部オレオレ認証局で署名、
各PCやブラウザにはオレオレルート証明書を１つインストールしておく
こんなのでいいよ
かえって危険になる (スコア:1)
ルート証明書の権限が強するので、オレオレルート証明書を入れるとかえって危険になるんだよね。
イントラアクセスするときには毎回ブラウザのセキュリティ警告無視した方がマシなレベル。
仮にオレオレ認証局のルート証明書の秘密鍵が漏洩したとする。
（インサイダーがHDD/SSDを直接読み取って鍵を盗んでも漏洩する）
そしてLAN内に悪意のあるホストが1台紛れさせて、そのホストはMACアドレスを詐称してルータに成り済ます。
でプレインストールアプリ等の https://.autoupdate.example.com/ [example.com] の通信を乗っ取って悪意のあるファイルを実行させることも可能。
OSプレインストールの既存の大手認証局と同レベルの管理ができないならばオレオレルート証明書をLAN内の端末にインストールする運用は止めた方がいい。
その認証局の秘密鍵が奪われたとき、LAN内のオレオレ証明書入れたマシンが一気に乗っ取られてしまう。
Re: (スコア:0)
一応、オレオレ認証局が勝手によそ様のドメインの証明書を発行することへの緩和策はいろいろある。が、ウェブブラウザ以外のクライアントの対応があまり期待できない状況だと思う。
Re: (スコア:0)
自己レス、DNSのCAAはオレオレ認証局対策にはならないな。すまん。
httpsを特別扱いする理由がない (スコア:0)
今どきフィッシングサイトもhttpsだし、DV証明書は相手の存在を全く保証しないので「安全の担保」には程遠い。
あと企業NWみたいな所ではhttpsだろうが傍受されて中身は覗かれてるし、httpsの「経路は安全」ってのもかなり嘘。
唯一httpsが有効に機能してる例は、悪意のある野良wi-fi経由で傍受されても大丈夫って所だけ。
httpを過度に危険視することで「httpsは安全」という誤解を招いてる方が有害だと思う。
Re:httpsを特別扱いする理由がない (スコア:1)
今までhttpsを「特別扱い」してきたけど、今後は「それが普通」にしようということ。
Re: (スコア:0)
安全策には必ずこういうアレルギー反応出るけどまあ恒例。
ノーヘルを過度に危険視する事でヘルメットしてれば運転は安全という誤解を…
みたいなもんだね。平文通信はありえない、これが最低限でしょ。
Re: (スコア:0)
安全策には必ずこういうアレルギー反応出るけどまあ恒例。
ノーヘルを過度に危険視する事でヘルメットしてれば運転は安全という誤解を…
みたいなもんだね。平文通信はありえない、これが最低限でしょ。
インターネットの特性上、むしろ「平文でも構わない」って通信の方が多いよ。
一方で「絶対に傍受されては困る」通信もある。
その間ってものはない。
ブラウザが実装すべきなのは「平文でも構わないものを強制暗号化」するより
「傍受されている可能性」を検出して警告出すことだと思うよ。
Re: (スコア:0)
平文通信は、その「傍受されている可能性」が高いから警告出してるんでしょうに。
Re: (スコア:0)
だったら傍受されてるSSLも警告出さないといけない。
片手落ちなんだよ。
Re: (スコア:0)
少なくとも検出可能な傍受の可能性をまず警告することに問題はないでしょ。
両手落ちてるよりは、片手だけでも凌ぐべき。
傍受されるSSLの検出は困難な場合が多い。(傍受自体も困難だけれども)
Re: (スコア:0)
傍受されてるSSLの検出って技術的にはそれほど困難ではなくて、自己署名証明書がサイト証明書に使われてると100%ビンゴ。
あと「ブラウザ開発元が信用したルート証明書以外」では、全て何らかの警告を出すこと(○○組織によって署名されています等)でも対応できる。
傍受を検出したら強制終了させるサイトもあるよね。そういうところはデコード除外設定するしかないってのをNW運用してれば経験するはず。
現実問題として傍受されてるSSLって100％ロギングされてるので、傍受されてるかされていないか不明なHTTP通信以上に危険な存在だよ。
なので片手落ちって話。より危険なものを認知できる手段を用意しないのに、それよりは低い危険性をさも「最も危険な通信」みたいに煽るなと。
Re:httpsを特別扱いする理由がない (スコア:1)
傍受検出で強制終了ではないけど、怪しい証明書を見かけたら報告するぞって仕組みは始まろうとしている。
Opt-out SCT Auditing in Chrome [google.com]
ただ、ウェブブラウザの証明書関係の機能、チェーンを辿るとプライベートなルート認証局だった場合はだいたい適用除外になる印象だよね。その点あまり期待できない。
Re: (スコア:0)
そんな簡単なものは検出と言うまでもないでしょ。
難しいのは、正規のルート証明書を不正利用されたもので、過去にも何度か問題が起きている。
Re: (スコア:0)
それは次元の違う問題。DVもEVも見分けることが困難になった現在は些細な問題。
あと正規ルートの証明書は傍受には使えない。
傍受製品はオレオレ証明書を動的作成したりTLDが*とか絶対に正規発行されない奴を使う。
Re: (スコア:0)
> インターネットの特性上、むしろ「平文でも構わない」って通信の方が多いよ。
プライバシーの概念捨ててる人相手にしてるとは思わなかった。
通信先は今の所隠蔽できないけど、最終的には全て不可視になるべきだと思うよ。
> 一方で「絶対に傍受されては困る」通信もある。
バイナリ思考だね。
Re: (スコア:0)
＞プライバシーの概念捨ててる人相手にしてるとは思わなかった。
プライバシー問題は経路上の話ではなくてcookieやトラッキングURLの問題。
あと常時SSLの話が出てきた頃はSSLデコードが一般的ではなかったので事情が変わってる。
Re: (スコア:0)
「常時傍受されている」のが「傍受されてるかどうかわからない」より危険ってのは、一般の感覚ではそうだけど、ちょっとでもセキュリティを齧ればそんな意見にはならないと思う。
Re: (スコア:0)
Junet時代から使ってますが？
Re: (スコア:0)
スラドのコメント、発信者や内容が盗聴可能だとしてもそれはそれでって感じだけど、
それを「プライバシーの概念捨ててる」って言われたらまあそれはそうだなって感じだし、
だからhttpで構わないという事になるんだけど、前提が違ってたら話が噛み合いようが無いわな。
httpsに統一した方がめんどくさくないならそれでいいんじゃないのと、秘匿されてなきゃダメなんだよの温度感の違いというか。
aviutl (スコア:0)
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モードを使ってハマってしまった…