[go: up one dir, main page]

この記事は Will Harris による Google Security Blog の記事 "Improving the security of Chrome cookies on Windows" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Cookie を盗む情報窃取マルウェアを使うサイバー犯罪者は、ユーザーの安全とセキュリティにリスクをもたらし続けています。この分野では、すでに多くの取り組みが実施されています。たとえば、セーフ ブラウジングによる Chrome のダウンロード保護、デバイス バウンド セッション認証情報、盗まれた Cookie が使われたことを検知する Google のアカウントベースの脅威検出などです。この度、新たな保護レイヤーについてお知らせします。これにより、この種のマルウェアから Windows ユーザーを保護する際の安全性が向上します。

Chrome は現在、秘密情報を保存する必要がある他のソフトウェアと同じように、OS が利用できる技術を使用して Cookie やパスワードといった機密データを保護しています。macOS ではキーチェーン サービスという技術を、Linux では kwallet や gnome-libsecret などのシステムが提供するウォレットを使っています。Windows の Chrome は、システムの他のユーザーやコールドブート攻撃から保存データを保護するために、データ保護 API（DPAPI）を使っています。しかし、悪意のあるアプリケーションがログイン中のユーザーとしてコードを実行できる場合、DPAPI では保護できません。

Chrome 127 で、DPAPI を改善する新しい保護機能を Windows に導入します。これは、アプリケーション バウンド（アプリバウンド）暗号化プリミティブを提供することによって実現します。Chrome は、ログイン中のユーザーとして実行されるアプリがこのデータにアクセスできるようにするのではなく、アプリの ID に紐付けてデータを暗号化できるようにします。これは、macOS のキーチェーンの動作と同様です。

今後、各種シークレットをこの新しいシステムに移行する予定ですが、Chrome 127 では、まず Cookie の移行を行います。今後のリリースでは、この保護をパスワードや支払いデータ、その他の永続的な認証トークンに拡大し、情報窃取マルウェアに対するユーザー保護をさらに強化する予定です。

動作の仕組み

アプリバウンド暗号化では、特権サービスを利用して要求元アプリケーションの身元を確認します。アプリバウンド暗号化サービスは、暗号化する際にアプリの ID をエンコードして暗号データに埋め込み、復号化が試行されたときにその有効性を確認します。システムに存在する別のアプリが同じデータを復号化しようとすると、失敗します。

アプリバウンド サービスはシステム権限で実行されます。そのため攻撃者には、単にユーザーを誘導して悪意のあるアプリを実行させる以上のことが必要になります。つまり、マルウェアはシステム権限を取得するか、Chrome にコードを挿入しなければならなくなります。これは、正規のソフトウェアが行うべきことではありません。そのため、動作の疑わしさが高まり、ウイルス対策ソフトウェアによって検出される可能性が高くなります。この保護とともに、Cookie 復号化のイベントログを提供するといった最近の取り組みも合わせて動作します。その目的は、ユーザーのデータを盗もうとする攻撃者のコストと検出リスクを高めることにあります。

企業での考慮事項

マルウェアは、昇格して実行することでこの保護をバイパスできます。そのため、エンタープライズ環境でダウンロードしたファイルを管理者として実行できないようにすることが特に効果的です。このような環境では、マルウェアが単純に昇格した権限を要求することはできなくなるので、インジェクションなどの技術を使わざるを得なくなります。このような操作は、エンドポイント エージェントでかなり容易に検出できます。

アプリバウンド暗号化では、暗号化鍵がマシンに強くバインドされるため、Chrome のプロファイルが複数のマシンをローミングする環境では正しく動作しません。ローミング プロファイルをサポートしたい企業には、現在のベスト プラクティスに従うことをお勧めします。必要な場合は、新しい ApplicationBoundEncryptionEnabled ポリシーを使ってアプリバウンド暗号化を構成できます。

互換性のない状況の検出に役立つように、Chrome は検証に失敗した際にイベントを発行します。イベントは、アプリケーション ログの「Chrome」ソースの ID 257 です。

まとめ

アプリバウンド暗号化により、攻撃者のデータ盗難コストは増加し、システムでの動作ははるかに目立ちやすくなります。また、システムの他のアプリに許容される動作について、防御側が明確な線引きを行うことができます。マルウェアの状況は継続的に進化します。それに合わせて、セキュリティ コミュニティの他のメンバーと協力しながら、検出の改善、強力なアプリ分離プリミティブといったオペレーティング システムの保護の強化など、バイパス対策の取り組みを続けていきたいと考えています。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Gabriel Charette、Olivier Li Shing Tat-Dupuis、Carlos Caballero Grolimund、François Doray による Chromium Blog の記事 "Introducing Shared Memory Versioning to improve slow interactions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



ほとんどの場合に高速であるだけでは不十分で、いつでも高速でなければならないというのが Chrome チームの考えです。今回の「速さと好奇心」の投稿では、ウェブに関する主な指標を向上させ、最終的にウェブのパフォーマンスを改善できた方法について取り上げます。これは、あらゆるウェブサイトでのユーザー インタラクションへの応答を表す Chrome のフィールド データを調査することによって実現しました。

日々、何十億人もの人々がさまざまなことにウェブを活用しています。ブラウザは同時に多くのアプリをホストしなければならなくなり、リソースの競合が課題になっています。マルチプロセス ブラウザである Chrome では、複数のリソースが競合しています。CPU やメモリはもちろんのこと、内部サービス（この記事では、ネットワーク サービス）間の専用作業キューもあります。

このような理由のため、私たちは Chrome ユーザーのフィールド データから遅いインタラクションを特定し、修正することに重点を置いています。このフィールド データこそ、実際のユーザー エクスペリエンスを表す確かな情報源です。このデータは、Chrome Canary 版で匿名化した Perfetto トレースを記録し、プライバシー保護フィルタを使って報告することで収集しています。

遅いインタラクションのフィールド データに注目したとき、ある 1 つの原因が浮かび上がってきました。それは、ネットワーク サービスから現在のサイトの Cookie を取得するため、同期呼び出しを繰り返し行っていることです。

その経緯から振り返ることにしましょう。

進化するウェブにおける Cookie

Cookie は、その創生期のころからウェブ プラットフォームの一部であり続けています。通常は、次のようにして作成します。

    document.cookie = "user=Alice;color=blue"

すると、次のようにして取得できます。

    // Assuming a `getCookie` helper method:
    getCookie("user", document.cookie)

シングルプロセス ブラウザでは、この実装はシンプルで、Cookie の器はメモリに保持されていました。

しかし時間が経つと、ブラウザはマルチプロセスとなり、Cookie の器をホストするプロセスは、ますます多くのクエリに答えなければならなくなります。ただし、ウェブの仕様では、Cookie は Javascript から同期的に取得できなければなりません。そのため、document.cookie クエリに回答する操作はブロック操作です。

この操作自体は非常に高速なので、通常、このアプローチは問題にはなりませんでした。しかし、高負荷シナリオでは、複数のウェブサイトがネットワーク サービスから Cookie（およびその他のリソース）をリクエストしており、リクエストのキューが滞る可能性があります。

遅いインタラクションのフィールド トレースから、一部のウェブサイトで、Cookie が連続して複数回フェッチされるという非効率的なシナリオが起きていることがわかりました。そこで追加の指標を作成し、すべてのナビゲーションでの冗長な GetCookieString() IPC（前回と同じ値が返されたもの）の頻度を測定しました。その結果、Cookie アクセスの 87% が冗長で、それが毎秒数百回発生している場合もあることがわかりました。これは驚愕の事実でした。

つまり、document.cookie のシンプルなデザインが裏目に出たということです。ウェブの JavaScript では、これをローカル値のように扱っていましたが、実際にはリモート検索が行われていました。これは、古典的なコンピュータ サイエンスのキャッシュを行えばよいケースでしょうか？！早まってはいけません！

ウェブの仕様では、協調ドメインが相互に Cookie を変更し合えることになっています。したがって、レンダラ プロセスごとの単純なキャッシュでは、うまくいきません。そのようなサイト間で書き込みが伝播されないからです（古い Cookie が残り、e コマース アプリケーションでカートが同期されなくなるなどの現象が発生します）。

新たなパラダイム : 共有メモリのバージョニング

これを解決したのが、私たちが共有メモリのバージョニングと呼ぶ新たなパラダイムでした。すなわち、document.cookie のそれぞれの値と、単調に増加するバージョン番号を組み合わせるという考え方です。各レンダラは、最後に読み取った document.cookie を、バージョン番号とともにキャッシュします。ネットワーク サービスは、そのバージョンのそれぞれの document.cookie を共有メモリにホストします。このようにすると、レンダラはネットワーク サービスにプロセス間クエリを送信しなくても、最新バージョンを保持しているかどうかがわかります。



この結果、Cookie 関連のプロセス間メッセージが 80% 削減され、document.cookie へのアクセスが 60% 速くなりました 🥳。

仮説の検証

アルゴリズムを改善するのは良いことですが、私たちが最終的に重視しているのは、改善によって遅いユーザー インタラクションが速くなったかどうかです。つまり、遅い Cookie クエリが遅いインタラクションの主要な原因であるという仮説を検証する必要があります。

これを実現するため、Chrome の A/B テスト フレームワークを使って効果を調査しました。その結果、すべてのプラットフォームで、他の改善によるリソースの競合の減少と合わせて、最も遅いインタラクションを約 5% 改善できたことがわかりました。そして、ウェブに関する主な指標を満たすサイトがさらに増加しています 🥳。こうしたすべてのことにより、ユーザーがさらにシームレスだと感じられるウェブが実現します。



Chrome におけるウェブで最も遅いインタラクションの加重平均のタイムライン。本機能が 1%（11 月）のユーザー、50%（12 月）のユーザー、すべてのユーザー（2 月）にリリースされるにあたっての状況。

シームレスなウェブに向かいましょう！


Posted by Eiji Kitamura - Developer Relations Team

この記事は Justin Donnelly による Chromium Blog の記事 "How Machine Learning improved the Chrome address bar on Windows, Mac and ChromeOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Chrome のアドレスバー（オムニボックスとも呼ばれます）は、毎日何十億回も使われているツールで、ウェブを簡単に検索できるようにしています。これを使うと、タブやブックマークをすばやく探すことも、以前にアクセスしたウェブページに戻ることも、情報を検索することもできます。

最新リリースの Chrome（M124）では、PC 版 Chrome のアドレスバーに機械学習モデルを組み込み、これまで以上に正確かつ適切にウェブページを提案できるようにしました。今後は、このモデルを使って、検索候補の関連性スコアの改善も行いたいと考えています。ここでは、今回の組み込みにつながったいくつかの重要な知見や、新しいモデルに期待されることについて、詳しくお伝えします。

これまでの経緯

アドレスバー担当チームのエンジニアリング リードである私にとって、すべてのリリースは特別なものですが、今回のリリースはとりわけ身近で大切なものです。初めて Chrome のアドレスバーに携わったとき、ユーザーに使いやすいと思ってもらうためのアイデアを周りに尋ねました。その 1 番の答えは、「スコアリング システムを改善する」でした。問題は、スコアが悪いことではありませんでした。実際、URL や検索語句を表示するアドレスバーの機能は、魔法のように感じられることがあります。問題は、それに 柔軟性がないことでした。 手作業で作成して調整する方法はうまく機能しましたが、それを改善したり、新しいシナリオに適応させたりするのは困難でした。そのため、スコアリング システムは長い間ほとんど手つかずのままでした。

その大半の期間、明らかに向かうべき方向となっていたのが、ML でトレーニングしたスコアリング モデルでした。しかし、ここにたどり着くまでに、多くの失敗を重ねることになりました。これほど長い間、この課題を解決できなかったのは、文字通り毎日何十億回も使われている機能の中核となる仕組みを置き換えるのが難しかったためです。ソフトウェア エンジニアリング プロジェクトは、「飛行機を飛ばしながら作る」と表現されることがあります。このプロジェクトは、「世界中のすべての飛行機が飛んでいる間に、すべての座席を交換する」ようなものでした。規模が非常に大きく、変更はすべてのユーザーに直接影響します。

有能で献身的なこのようなチームの努力がなければ、この野心的な取り組みは不可能でした。途中でぶつかったり、壁を突破しなければならなかったり、予期せぬ問題が発生してペースが落ちることもありましたが、ユーザーのためにどうしても正しい形でこれを行いたいという誠実な気持ちに突き動かされてきました。

意外な知見

ML システムで作業する楽しみの 1 つは、個人やチームでは困難または不可能な規模で、 すべての データを考慮したトレーニングを行えることです。そして、それは意外な知見につながる可能性があります。

このプロジェクトで一番驚いたのは、特定のシグナル、すなわち前回のナビゲーションからの時間のスコアリング曲線を見たときでした。このシグナルで期待されるのは、小さいほど（特定の URL に移動したのが最近であるほど）、関連性スコアが高くなることでした。

そして実際に、モデルはそのように学習しました。しかし、詳しく見てみると、驚くべきことがわかりました。ナビゲーションからの時間が非常に短い場合（数時間、数日、数週間ではなく、数秒だった場合）、モデルが算出する関連性スコアは、 減少 していたのです。トレーニング データを確認したところ、ユーザーが実際には望んでいない URL に移動し、すぐに Chrome のアドレスバーに戻って、もう一度試すパターンが記録されていることがわかりました。その場合、移動した URL は、ほぼ間違いなく、ユーザーが望んだものでは ありません。そのため、2 回目の試行との関連性スコアは低くなるはずです。

よく考えてみれば、これは当然のことです。そして、ML でスコアリングを始めていなければ、このシナリオを反映させるために、古いシステムに新しいルールを追加していたはずです。しかし、トレーニング システムは、このパターンを見つけて学習してくれました。その前には、このようなことが起きているとは、誰も想像できませんでした。

今後について

この新しい ML モデルを使って、ユーザー エクスペリエンスを向上させる多くの新しい可能性を開くことができると考えています。たとえば、1 日の中の時間帯を区別して関連性を向上させるなど、新たなシグナルを組み込むことができます。モバイル、エンタープライズ、アカデミックといったユーザーごとに、あるいは言語や地域の違いなどに応じて、特定の環境向けの特別なバージョンのモデルをトレーニングすることも模索したいと考えています。

さらに、ユーザーが Chrome のアドレスバーを操作する方法は、時間の経過とともに変化することがわかっています。そのため、関連性スコアもそれに合わせて変化させる必要があると考えています。新しいスコアリング システムを使えば、これまで以上に新鮮なシグナルを収集し、時間の経過とともに新しいモデルを定期的に再トレーニング、評価、展開することができます。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Nico Jersch による Chromium Blog の記事 "A new way to seamlessly browse across devices with Chrome on iOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome はすべてのプラットフォームで優れた機能を発揮するように設計されているので、自宅から PC でウェブをブラウジングするときも、外出先からスマートフォンでブラウジングするときも簡単に使えるようになっています。例えば、Chrome sync のようなツールによって、すべてのデバイスを切り替えてもブックマークやパスワードにアクセスできるようになりました。

今後数週間で iOS 版 Chrome に変更を加え、特に重要な情報をすぐ利用できるようにします。デバイスで Chrome 同期を設定する必要がなくなり、Chrome にログインするだけで、新しい情報を Google アカウントに保存したり、既存の情報にアクセスしたりできるようになります。iOS ですでに動作している Google アプリの数が多いため、これに慣れ親しんでいるように感じるかもしれません。Chrome にサインインすると、ブックマーク、リーディングリスト、パスワード、支払い情報、住所、設定など、重要な情報をアカウントに保存できます。また、タブと閲覧履歴を iOS の Chrome から Google アカウントに別々に同期させることもできます。これにより、別のデバイスで中断した閲覧を再開できます。




以上のアップデートは、データ管理にも役立つように設計されています。Chrome にログインすると、すでにデバイスに保存されている閲覧データは、デバイスのローカルデータとして別に保管されます。ローカルデータとアカウント データは、設定で簡単に区別できます。また、他のデバイスでローカルデータを利用できるようにしたい場合は、設定に移動してアカウントに保存することもできます。

iOS での Chrome へのログインは、今後とも完全に任意です。ログインしなくても、ブックマークやパスワードなどは保存できますが、保存したデバイスでのみ利用できます。また今後も、Chrome にログインしないまま、Gmail などの Google のウェブサービスにログインすることができます。

これらの変更により、求められるあらゆる柔軟性を提供するとともに、さらに簡単に Chrome を活用できるようになることを期待しています。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Chrome セキュリティ チーム、Chrome ルート プログラムによる Chromium Blog の記事 "Unlocking the power of TLS certificate automation for a safer and more reliable Internet" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

TL;DR: 証明書の発行と管理を自動化し、アジリティとレジリエンスを高めることで、Transport Layer Security（TLS）によるセキュリティ保証基盤を強化できます。この投稿では、ウェブ セキュリティの向上に向けた Chrome セキュリティの継続的な取り組みの一環として行われる自動化のメリットと Chrome ルート プログラム ポリシーの変更予定について説明します。

はじめにインターネットでユーザーのセキュリティを強化するために特によく使われているツールが、「Transport Layer Security」（TLS）です。これは以前、「セキュア ソケット レイヤ」（SSL）と呼ばれていました。TLS の最も基本的なレベルにあるのは、データを暗号化し、意図された受信者のみが読み取ることができるようにするセキュリティ プロトコルです。


暗号化によってインターネットは安全になりますが、それは信頼性の高い方法で一貫して導入されている場合に限ります。TLS 証明書の発行や管理の自動化などの最新の慣習を取り入れることで、この目標の実現に近づくことができます。

背景: TLS - インターネット暗号化通信の土台TLS は、皆さんが考える以上に身近なものです。というのも、これは HTTPS の「S」（「セキュア」を表す）であり、その土台となるテクノロジーだからです。最近の記事では、HTTPS は今や標準であり、Android、Chrome OS、macOS、Windows 版の Chrome のページ読み込みの 92% 以上が HTTPS で転送されていることを紹介しました。


暗号化プロトコルである TLS は、ウェブブラウザとウェブサーバー（ユーザーが閲覧するウェブサイトがホストされている場所）との間に安全なチャネルを確立します。その中核となるセキュリティ特性を次に示します。
  • 暗号化: 送信されるデータが、サードパーティや意図しない受信者によって傍受されたり、解釈されたりしないことを保証する。
  • 認証: ウェブブラウザが接続しているウェブサーバーやアプリケーションが、名乗っているとおりのものであることを保証する。
  • 完全性: 転送中にデータが改変されていないことを保証する。
TLS 接続を確立するために、ウェブブラウザとサーバーは自己紹介し合い、今後、継続的に接続を保護するルールに同意します。この自己紹介を「TLS ハンドシェイク」と呼びます。TLS 接続がどのように確立されているかを詳しく確認し、さらに理解を深めたい場合は、こちらのリソースをご覧ください。

TLS ハンドシェイクに欠かせないのが、X.509 証明書です。これは、「証明書」や「TLS 証明書」、「サーバー認証証明書」と呼ばれることもあります。証明書は、「認証局」（CA）と呼ばれる信頼できるエンティティによって発行されます。証明書の役割は、ドメイン名（例: google.com）の正当性を保証したうえで、対応する公開鍵にバインディングすることです。ウェブブラウザが正当なウェブサーバーと通信していることを確認できるのは（サーバー ID 検証）、この証明書があるからです。

ただし、TLS は完璧なソリューションではなく、ウェブサイトが絶対に安全であることを保証するものでもありません。TLS で保証されるのは、対応するウェブサーバーとの通信が暗号化されることであり、コンテンツの安全性やセキュリティではありません。フィッシングや、マルウェアやウイルスといった悪意のあるコンテンツがウェブサイトのユーザーに送られることは、TLS では防げません。Chrome 117 以降では、アドレスバーの鍵アイコンに代わって、セキュリティを連想させない新たな「調整」アイコンが表示されていますが、その理由の 1 つは、「暗号化」（TLS が提供するセキュリティ特性）と「安全」（主観的な感覚）という用語によってもたらされる可能性がある誤解を排除することにあります。

自動化の力以上のように、サーバー認証証明書は、ウェブブラウザとウェブサーバーとの間の暗号化接続を支えています。信頼されたパブリック証明書（Chrome などのプロダクトでデフォルトで信頼されている証明書）は、CA / ブラウザ フォーラムの「ベースライン要件」や Chrome ルート プログラム ポリシーなど、業界全体とウェブブラウザ固有のポリシーの両方に準拠する必要があります。そのような要件の 1 つでは、証明書の最長有効期間が 398 日以内であることが定められています。

証明書の有効期間は、RFC 5280 で定義されており、証明書の TLS 接続を確立できる機能が最長でいつまで有効であるかを表します。現在、証明書の最長有効期間は 398 日に設定されていますが、常にそうだったわけではありません。わずか 10 年余りの間に、証明書の有効期間のトレンドは、期限なしから 60 か月（2012 年）、39 か月（2015 年）、825 日（2018 年）、398 日（2020 年）へと変わりました。最長有効期間の短縮の根底には、常に同じ狙いがありました。それはセキュリティの向上です。

証明書の有効期間を短くすることは、ユーザーの保護につながります。証明書の鍵が侵害されたときの影響を軽減でき、ウェブ全体で安全でないテクノロジーや慣習がすばやく置き替わることになるからです。鍵が侵害されたり（ウェブサーバーの証明書に対応する秘密鍵が誤って、または意図的に漏洩されること）、インターネット セキュリティの脆弱性が発見されたり（Heartbleed バグなど）するのは、一般的なできごとです。それが現実世界の被害につながる可能性があるので、ウェブユーザーはこういった問題から守られるべきです。

証明書の有効期間は短くなり、組織が利用する証明書の数は増えています。そのため、ウェブサイト運営者は、証明書やそれに対応する基盤の管理をスピードアップすることが求められています。アジリティ、信頼性、セキュリティを向上させるための最善策の 1 つが自動化です。


証明書の自動化とは証明書の自動化に汎用的な定義はありませんが、1 つの共有要素があります。それは、証明書の最初の発行や継続的な更新の際に、人間の「手作業」による入力が最小限に抑えられるか、必要なくなることです。証明書の管理は複雑でエラーが発生しやすい作業ですが、それが証明書の自動化によって簡素化されるので、セキュリティや運用効率が向上します。

ウェブ公開鍵基盤（「Web PKI」）には、主に 2 種類の証明書自動化ソリューションがあります。自動証明書管理環境（ACME）プロトコルなどの標準を利用するオープン ソリューションと、独自のツールやプロトコルを利用するソリューションです。

自動化のメリット証明書の発行と管理の自動化には、次のような効果があります。

  • アジリティが向上する。
    • 自動化により、新しいセキュリティ機能のメリットを実現するスピードが向上します。
  • レジリエンスと信頼性が向上する。
    • 自動化によって人為的なミスを排除でき、証明書管理プロセスを複雑な環境全体に拡張できます。
    • 証明書の期限が切れると、ウェブサイトが停止し、トラフィック、評判、収益の損失につながる可能性があります。自動化とモニタリングを組み合わせることで、それを防ぐことができます。
    • ACME Renewal Information（ARI）などのイノベーションを活用すれば、予期せぬできごとを発端とするウェブサイトの停止からシームレスに保護されます。ARI を導入すると、たとえば、インシデントが原因で証明書が取り消される前に、CA は所定の期間内に証明書の更新が必要であることをウェブサーバーに伝えることができるようになります。
  • 効率が向上する。
    • 自動化により、証明書の手動管理に必要な時間やリソースを削減できます。自動化には初期投資が必要ですが、長い目で見れば、チームメンバーは戦略的で付加価値の高い活動に集中できるようになります。

自動化がセキュリティの向上につながる理由自動化によって、セキュリティ態勢が改善され、CA インシデント、インターネット セキュリティの脆弱性、暗号化のサポート終了などの予期せぬできごとに対応する際のレジリエンスが向上します。

CA インシデントベースライン要件には、一部の種類の CA インシデントに期待される対応が規定されています。その多くの対応に含まれるのが、影響が及ぶ証明書を信頼できなくなった（「取り消された」）ものとしてマークする操作です。4 年前のことですが、Let's Encrypt は、300 万個以上の証明書に影響を及ぼしたバグを自己申告しました。このインシデントに対応して、約 200 万個の証明書が取り消されました。つまり、ウェブサイトが停止する可能性をなくすために、運営者が介入して置き換えを始める必要がありました。ここまでの規模のインシデントは珍しいものの、証明書の再発行が必要になる Web PKI インシデントは一般的です。

このインシデントから、2 つの重要な結論が得られます。1 つ目は、Let's Encrypt が率先して導入を進めてきた ACME プロトコルのおかげで、影響を受けたウェブサイト運営者がわずかな手作業でインシデントから復旧できたことです。影響を受けた証明書のうち、170 万個以上は 48 時間以内に交換されました。2 つ目は、Let's Encrypt がこのインシデントを受けて、新しいプロトコル（上記の ARI）を開発して展開することを宣言したことです。このプロトコルは、人間の介入なしに自動的に証明書を置き換えられるようにして、将来の CA インシデントへの対応を改善することを可能にします。Let's Encrypt は、2023 年 3 月に ARI の本番環境への導入を発表しました。他の CA も、このオープン プロトコルを導入してインシデント対応を改善できるようになっています。

インターネット セキュリティの脆弱性 2014 年 4 月、インターネットの大部分のサーバーを保護するために使われている一般的な暗号化ソフトウェア ライブラリで、セキュリティ脆弱性（「Heartbleed」）が発見されました。これにより、TLS によって提供されるセキュリティ特性が破られました。アクティブでパブリック アクセス可能なサーバー認証証明書のうち、このバグへの対応として取り消して置き換える必要があった証明書は、50 万個を超えたと推定されています。脆弱性が実証されていたにもかかわらず、ウェブサイト運営者による修復作業はなかなか進みませんでした。影響を受けたウェブサイトのうち、開示後 1 か月以内に必要な修復手順を完了したウェブサイトはわずか 14% でした。また、影響を受けたデバイスの約 33% は、開示から約 3 年後も脆弱なままでした。

当時のベースライン要件で許可されていた証明書の最長有効期間は 5 年間でした。TLS 構成の状態を再確認しなければならないのは数年先だと誤認していたウェブサイト運営者もいました。これは、修復がなかなか行われなかった一因にもなっています。さらに、証明書を取り消すことを選択した CA は、取り消し情報のホスティングに関連する多額の費用に直面しました。1 つの CA 当たりの推定費用は、月額 40 万ドルから95 万 2,992.40 米ドルと見られています。ベースライン要件では、CA が発行する各証明書の取り消し情報は、有効期間が終了するまでホストすることが義務付けられています。つまり、このコストは数年間にわたって継続しなければならないということです。そのため、ウェブのセキュリティを支える組織は、財務的に重大な影響を受ける可能性があります。

控えめに言っても、ACME や ARI のような最新の自動化技術を利用すれば、影響を受ける証明書の再発行に必要な手作業を減らすことができます。Certbot や Lego など、よく使われている ACME クライアントでは、脆弱な秘密鍵が再利用されることを懸念して、証明書のリクエストごとに新しい鍵素材を自動的に作成します。また、証明書の有効期間を短くする可能性に思い至っていれば、攻撃できる最長の期間は 5 年よりも大幅に短くなっていたはずです。自動化が進めば、証明書の有効期間が短くなっても、簡単に移行できます。実際、多くのサイトで使われているのは、現時点の最長である 398 日よりもはるかに短い有効期間の証明書です。たとえば、Facebook は証明書の発行と管理のワークフローを高度に自動化し、わずか数日しか使用できない証明書によって、ネットワーク エッジと対応するデバイスを保護しています。他の CA は、30 日間だけ有効な証明書をデフォルトとしています。最後の興味深い点は、ある査読済みの研究によって示されています。それは、Heartbleed で求められた手動介入に対し、自動化を実装したシステム管理者は、そうでないシステム管理者と比べて、証明書の置き換えが速かったことです。

暗号化のサポート終了証明書のセキュリティの中心となっているのが、暗号化ハッシュ関数（任意のサイズの入力から固定長の出力を生成する数学アルゴリズム）です。2005 年、ある研究者グループによって、広く使用されていた SHA-1 ハッシュ関数の最初の脆弱性が実証されました。セキュリティの懸念が高まってきたため、Chrome では 2014 年にサポート終了スケジュールを発表しました。最終的に CA / ブラウザ フォーラムは、2016 年 1 月 1 日以降、SHA-1 を使用する証明書の発行を禁止しました。

残念なことに、このサポート終了の対応には何年もの年月が必要でした。ブラウザは、大規模な不具合を避けるため、影響を受けるほぼすべての証明書が更新されるのを待たなければならず、そのほとんどは手動でした。ACME や ARI などの最新の自動化技術があれば、影響を受ける証明書の再発行に必要な手作業は減っていたでしょう。さらに、証明書の有効期間が短くなっていれば、SHA-1 からの移行ははるかに速く終わっていたはずです。そして、この暗号の脆弱性は理論上だけのものではありませんでした。2017 年 2 月には SHA-1 の壊滅的な脆弱性が実証されました。Chrome では、影響を受ける証明書のサポートを削除する作業を数週間前に終えたばかりだったため、かろうじて危機を回避できました。

暗号化のサポート終了は、皆さんが考えるほど珍しいものではありません。TLS や PKI の暗号は次々と古くなるため、Chrome では、できれば脆弱性が明らかになる前に、古い暗号を根絶して最新の方式を利用できるように作業を進めています。

失敗の可能性とコスト証明書の期限が切れると、ウェブサイトはダウンするので、生産性が低下し、評判が下がり、サービスレベルの期待値を満たせなくなります。

昨年リリースされた Chrome バージョン（Chrome 106 以降）で見られた TLS 接続失敗をすべてのプラットフォームで確認したところ、22% 以上は有効期間が無効な証明書によるものでした。

2019 年の調査によると、すべての HTTPS サイトの 3.9% で、証明書の期限が切れています。

エコシステムの自動化状況 2022 年 12 月から 2023 年 1 月にかけて、Chrome Root Store に追加されている CA オーナーを対象としたアンケートを実施しました。調査の目的は、証明書の発行や管理を自動化するソリューションの導入状況や採用予定を細かく把握することでした。

証明書の透明性ログや crt.sh などのツールで公開されているデータと合わせて考えると、現在 ACME プロトコルを使っているのは、Web PKI で発行された証明書の 58% と推定されます。多くのウェブサイト運営者が ACME による証明書の発行や管理を支持しているのは明らかで、そこから考えれば、Web PKI の証明書自動化の需要も高まっていると言えます。この調査からは、Web PKI の証明書の 95% 以上が、現在 ACME をサポートしており、Chrome Root Store に追加されている CA オーナーによるものであることもわかりました。ACME サービスの需要が増えたと報告している CA オーナーは、対象の 70% にのぼります。これは、エコシステム全体で、ACME ユーザー数が健全に増加している強力な指標であると解釈できます。現在 ACME をサポートしており、ACME の需要が減少していると回答した CA オーナーはありませんでした。

Chrome Root Store に追加されている CA オーナーの中には、別種の証明書の発行や管理の自動化ソリューションを提供しているところもあります。この点について理解を深めるため、2023 年 4 月から 6 月にかけて、別のアンケートを実施しました。再び、証明書の透明性ログや crt.sh などのツールで公開されているデータと合わせて考えると、現在 Web PKI で発行されている証明書の 80% 以上が、何らかの自動化（ACME を含む）によるものであることがわかります。Chrome Root Store に追加されており、自動化に対応していないと申告した組織による Web PKI 証明書は、全体の約 0.08% を占めていました。

自動化への取り組み Chrome ルート プログラムでは、Chrome でデフォルトで信頼される CA のセットを決定するためのガバナンスとセキュリティ審査が提供されています。Chrome ルート プログラムについては、以前にブログで紹介しましたが [1 および 2]、見逃してしまった方のために説明すると、次の方法でユーザーのオンラインの安全を確保しています。

ポリシーおよびガバナンス アクティビティの管理を通じて、Chrome でデフォルトで信頼される CA セットを管理する。

参加している CA が開示したパブリック セキュリティ インシデントの影響やそれによるセキュリティの懸念を評価する。

エコシステムのレジリエンスを高めるために、ポジティブな変化をもたらす。

最後の点の具体的な内容として、2022 年 6 月リリース版（バージョン 1.1）の Chrome ルート プログラム ポリシーでは、「ともに、未来へ」（Moving Forward, Together、MFT）という取り組みが紹介されました。この取り組みの目的は将来のビジョンの共有で、その中には、自動化、簡素化、セキュリティに重点を置き、信頼性が高く、非常にアジャイルな最新の目的主導型 PKI などが含まれています。

ともに、未来へ「ともに、未来へ」は規範的なものではないため、ポリシーではありません。これが表すのは、私たちが Web PKI エコシステムのメンバーと協力し合って実現したい未来像です。MFT に記載されている関連提案が幅広いエコシステムに与える影響を調査し、理解するため、私たちは次のことを行っています。
  • crt.sh や Censys など、一般公開されているツールで生成されるエコシステムのデータを調査する。
  • Chrome のツール、試験運用、使用状況データから得られたデータを解釈する。
  • 査読済みの研究を評価する。
  • 前述の自動化ソリューションに関するものなど、アンケートを通じてフィードバックを収集する。
MFT の取り組みの中には、CA / ブラウザ フォーラム内のコラボレーションによって達成できるものもあります。または、Chrome ルート プログラム ポリシーにのみ変更を適用するほうがが適切な場合もあります。CA / ブラウザ フォーラムのベースライン要件に準拠している CA オーナーのすべてが、Chrome の主要なサーバー認証 PKI のユースケースを提供しようとしているわけでも、Chrome でデフォルトで信頼されることを希望しているわけでもないためです。ただし、最終的に提案がどのように実現されるかにかかわらず、それが適切かつ可能である場合には、コミュニティ メンバーと協力して、エコシステムへの悪影響を最小限に抑えることを目指します。

今後のポリシー変更の予定先週行われた CA / ブラウザ フォーラムの第 60 回対面ミーティングでお知らせしましたが、Chrome Root Store に追加されている CA オーナーからのフィードバックと明確化リクエストを集めるため、Chrome ルート プログラム ポリシーの更新版をまもなくプレリリースします。

バージョン 1.5 の主なポイントは、Chrome Root Store への追加を希望する申請者に、証明書の発行と管理の自動化が義務づけられることです。2 月と 6 月に行われた対面ミーティングでお知らせした最新情報を含めて、この 1 年を通じて自動化を義務づける意図について説明してきました。

こういった新しい要件は、Chrome Root Store の申請者が「自動化されていない」方法で証明書の発行や更新を行うことを禁止するものでも、ウェブサイト運営者が自動化ソリューションのみを使って証明書の発行や更新を行うことを求めるものでもありません。このポリシーの更新の目的は、CA オーナーの顧客が証明書の自動発行を選択できるようにすることです。

私たちは、独自のプロトコルやツールを使うソリューションよりも、ACME ソリューションを推奨しますが、新しいポリシー要件が意図している内容は、どちらの形式の自動化でも満たされます。さらに明確に言うなら、ACME を推奨する理由は、幅広いエコシステムが対応し、採用しているからです。また、ACME はオープンであり、継続的なイノベーションと、強力なエコシステムの参加者たちが進める機能強化による恩恵を受けています。ACME のクライアント オプションには詳細なドキュメントが豊富にあり、さまざま言語とプラットフォームに対応しています。そのうえ、ACME は、Web PKI の TLS 証明書を発行するというニーズに特化した設計になっています。

自動化にまつわる今後の可能性証明書の発行と管理の自動化を幅広く普及させる活動によって、次世代の Web PKI のための重要な基盤が確立されることになります。自動化の活用が増えれば、今後、さらに近代的でアジャイルな基盤が誕生する可能性が生まれ、強固なセキュリティ特性を実現できます。たとえば、欠点を最小限にとどめつつ、証明書の最長有効期間を短縮できます。

すべてのウェブサイト運営者が自動化を選択できるようにするには、Web PKI エコシステムのメンバー（ウェブブラウザ、CA、ウェブサイト運営者、ホスティング プロバイダなど）が継続的にコラボレーションする必要があります。ACME Renewal Information やサブドメインの自動証明書管理環境など、ACME エコシステムの最近の進展は励みになります。こういった取り組みの目的は、証明書のステータスに影響を与えたり、停止につながったりする予期せぬできごとからウェブサイト運営者を守ること、そして ACME が一般的なサーバー認証のユースケースをサポートしやすくすることにあります。フェイルオーバー関連の処理は、さらに改善できる余地があります（リクエスト時に優先プロバイダが利用できない場合、新しい CA にスムーズに移行するなど）。自動化を導入する顧客をサポートできる CA オーナーが増えれば、こういった進展が継続し、ウェブサイト運営者がサーバー認証証明書を安全かつ簡単に取得、管理できるようになるはずです。

詳細を見るウェブサイト運営者であるなら、証明書の発行と管理の自動化がもたらす可能性について考えてみましょう。ぜひ今すぐ始めてください。さらに詳しく知りたい方のために、以下にリソース一覧をまとめます。ただし、関係する CA オーナーに連絡し、サポートの状況や自動化計画の有無を確認することをお勧めします。

リソース証明書の発行と管理を自動化するソリューションの導入についてすでに調査したことがあり、それが困難すぎる、または障害が多すぎて実現できないと判断したことがある方は、ぜひ再検討してみてください。Web PKI は進化を続けており、最近の進展により、自動化の採用はこれまで以上に容易になっています。Caddy のような最新のウェブサーバー プラットフォーム プロバイダでは、ウェブサイト運営者がデフォルトで TLS を設定しやすくなっています。多くのサードパーティ ホスティング プロバイダ組織も同様です。

証明書の発行と管理の自動化に対応していないソフトウェアやサービス プロバイダを利用している場合は、この投稿を共有し、プロダクトの今後のロードマップに自動化を含めるよう依頼しましょう。

最後になりますが、証明書の自動化に関連する課題や教訓、改善の機会を共有したい方は、chrome-root-program [アットマーク] google [ドット] com までお知らせください。

注: この投稿に記載したサービス プロバイダについては、すべてを網羅しているわけでも、いずれかを推奨しているわけでもありません。あくまでも情報提供のみを目的としたものです。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Chrome セキュリティ チーム、Joe DeBlasio による Chromium Blog の記事 "Towards HTTPS by default" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ここ数年間、すべての主要プラットフォームでは、Chrome ユーザーのナビゲーションの 90% 以上が HTTPS サイトを対象としたものになっています。幸いなことに、ほとんどのトラフィックは暗号化された正当なものであり、ネットワーク攻撃者から保護されています。しかし、HTTP は 5～10% のトラフィックで根強く使われ続けているため、攻撃者はそのデータを盗聴したり変更したりできます。サイトへの接続が安全でない場合、Chrome のアドレスバーに警告が表示されますが、私たちは不十分だと考えています。多くのユーザーが警告に気づかないだけでなく、警告に気づいたときには、すでに損害が発生している可能性があるからです。

私たちは、ウェブはデフォルトで安全であるべきだと考えています。そして、それを実現するのが HTTPS ファースト モードです。このモードでは、Chrome で安全でないサイトに接続する前に、ユーザーから明示的な許可が必要になります。私たちの目標は、最終的にすべてのユーザーに対して、デフォルトでこのモードを有効にすることです。現時点では、HTTPS ファースト モードを例外なく有効にする準備はまだ整っていませんが、その目標に向かうためのいくつかの重要なステップをお知らせします。

自動アップグレードChrome は、すべての http:// ナビゲーションを自動的に https:// にアップグレードします。明示的に http:// と記述されたリンクをクリックした場合も同様です。これは HSTS のアップグレードととてもよく似た動作ですが、アップグレードに失敗すると（例: 無効な証明書を提供するサイトや、HTTP 404 を返すサイトなど）、自動的に http:// にフォールバックします。この変更により、Chrome で安全でない HTTP が使われるのは、どうしても HTTPS が利用できない場合のみになります。安全でない古いリンクがクリックされた結果、HTTP が使用されるわけではありません。現在、ウェブ全体での動作の標準化に向けて、Chrome のバージョン 115 でこの変更の試験運用を行っています。この機能は、近日中にすべてのユーザーに公開する予定です。これは、能動的にネットワークを攻撃する攻撃者からの保護にはなりませんが、すべての人に HTTPS ファースト モードを導入する足がかりとなり、受動的にネットワークを盗聴する攻撃者から、さらに多くのトラフィックが保護されるようになります。

安全でない方法でダウンロードされたファイルへの警告これまでの取り組みで混合ダウンロードを廃止しましたが、それを発展させて、安全でない接続を通してリスクの高いファイルをダウンロードする前に、Chrome に警告を表示するようにします。ダウンロードされたファイルには、Chrome のサンドボックスなどの保護をバイパスする悪意のあるコードが含まれている可能性があります。そのため、安全でない方法でダウンロードすると、ネットワーク攻撃者にコンピュータを攻撃する好機を与えてしまいます。この警告の目的は、ユーザーにリスクを知らせることです。リスクを許容できるなら、ファイルをダウンロードできます。HTTPS ファースト モードが有効になっていない場合は、画像、オーディオ、ビデオなどのファイルを安全でない方法でダウンロードしても、警告が表示されることはありません。これらのファイル形式は比較的安全です。この警告は、9 月中旬より表示されるようになる予定です。
安全でない方法でファイルをダウンロードすると、Chrome に通知が表示される。
安全でない方法でファイルをダウンロードすると、Chrome に通知が表示される。

HTTPS ファースト モードの保護対象ユーザーの拡大
私たちの最終的な目標は、すべてのユーザーが HTTPS ファースト モードを利用することです。これを実現するため、HTTPS ファースト モードの保護機能をいくつかの新しい領域に拡張します。
  • Google の高度な保護機能プログラムに登録済みで、Chrome にログインしているユーザーに対して、HTTPS ファースト モードを有効にしました。これらのユーザーは、提供されている最強の保護を Google に求めています。ユーザーが直面しているのは安全でない接続がもたらす現実的な脅威であり、HTTPS ファースト モードは、そういった脅威を回避するために役立ちます。
  • 近日中にシークレット モードのデフォルトで HTTPS ファースト モードを有効にし、ブラウジング体験をさらに安全なものにしたいと考えています。
  • 現在、Chrome では、通常はユーザーが HTTPS でアクセスすると認識されているサイトを対象に、HTTPS ファースト モードの保護を自動的に有効化する試験運用を行っています。
  • さらに、HTTP をほとんど使っていないユーザーに対して、HTTPS ファースト モードを自動的に有効化することを検討しています。
試してみるHTTPS のアップグレードや安全でないダウンロードに対する警告がすべてのユーザーにロールアウトされる前に試してみたい方は、chrome://flags で [HTTPS Upgrades] フラグと [Insecure download warnings] フラグを有効にすると、すぐに試すことができます。さらに保護を強化したい場合は、Chrome のセキュリティ設定（chrome://settings/security）で [常に安全な接続を使用する] を有効にして、HTTPS ファースト モードをオンにすることもできます。

デベロッパーおよび企業向けの情報
デベロッパーの皆さんは、HTTPS を使い、HTTP でしかアクセスできないコンテンツをホストしないようにすることで、ユーザーに警告が表示されたり、サイトのアップグレードが失敗したりすることを回避できます。お勧めの方法は、完全に HTTPS を採用し、すべての HTTP URL を HTTPS にリダイレクトすることです。サイトに個人情報が含まれていないと考えていても、HTTP を使っていれば、ネットワーク攻撃者によってブラウザに悪意のあるコンテンツが挿入されるリスクが高まります。悪意のあるネットワーク攻撃者は、セキュリティで保護されていないサイトを足がかりとして、ユーザーを攻撃します。ユーザーが安全でないウェブサイトにアクセスすることでもたらされるリスクを軽減するため、その他の方法も模索しています。たとえば、HTTP でアクセスできる Cookie の有効期間の短縮などです。今のうちに HTTPS に切り替えておけば、今後の変更によってユーザーのエクスペリエンスに影響が及ぶことはなくなります。まだ HTTPS に対応できない場合は、サーバーがポート 443 のリクエストにまったく応答しないようにするか、HTTPS から HTTP にリダイレクトすると、確実にサイトにアクセスできるようになります。

企業や教育機関のネットワークに独自のニーズがあることは承知しています。HttpsOnlyMode、HttpsUpgradesEnabled、HttpAllowlist、InsecureContentAllowedForUrls の各ポリシーを使うと、以上の機能を早い段階でオンにしたり、カスタマイズしたり、完全にオフにしたりできます。

継続的な取り組みの一環
Chrome には、デフォルトで安全なウェブを目指して取り組んできた長い歴史があります。そして、私たちはここで立ち止まるわけではありません。ゴールは間近に迫っています。ウェブがデフォルトで HTTPS になるときを心待ちにしています。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Devon O'Brien による Chromium Blog の記事 "Protecting Chrome Traffic with Hybrid Kyber KEM" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google のチームは、ウェブを量子耐性暗号に移行する準備を整えることに注力しています。この大きな変革に対応するための戦略を継続しながら、技術標準を更新し、新しい量子耐性アルゴリズムをテストおよび展開しているほか、この取り組みを成功させるために幅広いエコシステムと連携しています。

この移行に向けた第一歩として、Chrome 116 から TLS での対称シークレットの確立に X25519Kyber768 がサポートされるようになり、Chrome 115 ではフラグを設定することで利用できるようになります。このハイブリッド メカニズムは、2 つの暗号アルゴリズムの出力を組み合わせて、TLS 接続の大部分を暗号化するために使用されるセッション鍵を生成します。

Google は、この変更に伴うエコシステムの非互換性を洗い出すために、このアルゴリズムを TCP と QUIC の両方で Chrome と Google サーバーに展開し、潜在的な互換性の問題をモニタリングしています。Cloudflare などのサードパーティ サーバー オペレーターがこのセッション鍵のサポートを追加した場合、Chrome は、当該サードパーティ サーバーに接続する際に、この更新された鍵合意を使用することもあります。この変更によって引き起こされたと思われる問題に遭遇したデベロッパーまたは管理者の方は、バグについてご報告ください。ここからは、この変更とその理由を理解するのに役立つ重要な背景情報について記載します。

ポスト量子暗号化へと向かう理由

TLS などの最新のネットワーク プロトコルは、情報の保護（機密性）やウェブサイトの ID 検証（認証）など、さまざまな目的で暗号を使用します。この暗号の強さは、攻撃者がこうした特性の 1 つ以上を侵害するのがどれほど難しいかという観点から評価されます。暗号化の分野では、攻撃はより強力になることはあっても弱くなることは決してない、とよく言われます。これは、攻撃が進化し、時間が経つほど手ごわくなるため、より強力なアルゴリズムへの移行が重要になることを強調しています。

そのような進化の一例として、既存のコンピューティング方式では不可能な特定の計算を効率的に実行できる量子コンピュータの開発が挙げられます。現在使用されている多くのタイプの非対称暗号化は、既存の技術を使用した攻撃に対して強いと考えられていますが、十分な能力の量子コンピュータを使用する攻撃者には対抗できません。

量子耐性のある暗号は、量子暗号解読技術と古典的暗号解読技術の両方に対しても安全でなければなりません。これは理論上の話ではありません。2022 年と 2023 年には、量子耐性暗号アルゴリズムの主要な候補のいくつかが、市販されている安価なハードウェア上で破られました。X25519Kyber768 などのハイブリッド メカニズムは、接続が既存の安全なアルゴリズムによって保護されることを保証しながら、新しい量子耐性アルゴリズムを展開およびテストする柔軟性を提供する必要があります。

こうした要求事項に加えて、このアルゴリズムは、市販のハードウェアでもパフォーマンスを発揮する必要があるため、問題がさらに複雑になります。


なぜ転送中のデータを保護することが、今重要なのか

現代の古典的な暗号を破ることができる量子コンピュータは、今から 5 年、10 年、おそらく 50 年後にも登場しないと考えられています。それでは、なぜ今、トラフィックの保護を始めることが重要なのでしょうか？その答えは、特定の用途の暗号は、今収集して後で解読（Harvest Now, Decrypt Later）と呼ばれる攻撃に対して脆弱だからです。この攻撃では、データは即座に収集されて保存されますが、解読は、暗号解読技術が改良された後で行われます。

TLS では、転送中のデータを保護する対称暗号化アルゴリズムは量子暗号解読に対して安全であると考えられていますが、対称鍵の生成方法はそうではありません。つまり、Chrome では、量子耐性のあるセッション鍵を使用するために TLS を更新するのが早ければ早いほど、将来の量子暗号解読からユーザー ネットワーク トラフィックをより早く保護することができます。

展開に関する考慮事項

X25519Kyber768 を使用すると、Kyber によりカプセル化された鍵素材が追加されるため、TLS ClientHello メッセージに 1 キロバイト以上の追加データが生じます。Google が以前行った、CECPQ 2 を用いた実験では、TLS 実装の大部分がこのサイズの増加に対応できることが実証されましたが、一部の特定のケースでは、メッセージ サイズに対する不適切なハードコード制限のために TLS ミドルボックスで動作不良が起きました。

これらの新しいアルゴリズムが展開される際に、ネットワーク アプライアンスの非互換性に対処しなければならない企業を支援するために、Chrome の管理者は Chrome 116 から利用可能な PostQuantumKeyAgreementEnabled エンタープライズ ポリシーを使用して、X25519Kyber768 を無効にすることができます。このポリシーは一時的な措置としてのみ提供されます。管理者は、影響を受けるプロダクトのベンダーと協力して、非互換性を引き起こすバグをできるだけ早く修正するよう強くお勧めします。

最終的なデプロイのための考慮事項として、X25519Kyber768 と Kyber の仕様はどちらもドラフト段階のものであり、最終的な決定の前に変更される可能性があり、Chrome の実装も変更される可能性があることに注意してください。

この記事は Joshua Cruz による Chromium Blog の記事 "Redesigning Chrome downloads, to keep you productive and safe online" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


ブログ投稿のメインイメージ。アドレスバーの右側にある Chrome の新しいダウンロード エクスペリエンスを紹介しています。


デスクトップ版 Chrome の最新リリースで、Chrome のダウンロード エクスペリエンスを刷新し、最近のダウンロードに対する操作をさらに簡単に行えるようにしました。Chrome シニア プロダクト マネージャーの Jasika Bawa から、今回の刷新の舞台裏について詳しい話を聞いてみましょう。

Chrome のダウンロードを刷新するという判断をしたのはなぜですか？

ダウンロードは日々のウェブ ブラウジングに欠かせない操作です。猫をテーマにした完璧な背景をパソコン用に入手することから、納税申告書のコピーを保存することまで、その用途はさまざまです。私たちは、Chrome の以前のダウンロード エクスペリエンスについてのフィードバックを長年にわたって受け取ってきました。中核的なダウンロード操作のサポートや潜在的に有害なファイルに対する組み込みの保護など、優れた機能がたくさんあることはわかっていますが、問題点もありました。たとえば、次のようなことです。

  • 画面下部の貴重なピクセルを占有するため、ウェブ コンテンツ領域が狭くなり、画面の幅によって一度に表示できるファイルの数が制限されていた
  • 自動で消えることがなく、固定のオーバーフロー メニューで提供されていたアクションは、一時停止や再開、フォルダを開くなどだけだった
  • モダンでインタラクティブなものでなく、他のブラウザの UI やブラウザのエコシステム全体の外観との整合性がなくなっていた

こういったすべての点について考えれば、ダウンロード エクスペリエンスをさらに直感的なものにするために、Chrome を改善する余地があったのは明らかでした。

今回の刷新によって提供すべきものは何ですか？

画面下部にあった以前のダウンロード エクスペリエンスに代わり、Chrome のアドレスバーの右側に新しいダウンロード トレイが表示されます。ダウンロードが進行中の場合、アニメーションするリングから一目で進行状況を確認できます。ファイルのダウンロードが終わると、トレイが開き、自動的に非表示になります。そのため、すばやく簡単にアクセスできるだけでなく、閲覧が中断することもありません。

Chrome ブラウザの GIF イメージ。カーソルが、ウェブファイルの「保存」オプションをクリックしています。ダウンロードが進行中であることを示すアイコンがあり、その周りに進行状況を表すリングが表示されます。ファイルのダウンロードが終わると、ダウンロード トレイが自動的に開きます。


ダウンロード トレイでは、過去 24 時間のすべてのダウンロードのリストを確認できます。このトレイは、ダウンロードを始めたブラウザ ウィンドウだけでなく、すべてのウィンドウから確認できます。トレイにはインライン オプションも用意されており、ダウンロードしたフォルダを開く、ダウンロードをキャンセルする、なんらかの理由で失敗したダウンロードを再試行する、ダウンロードの一時停止や再開を行うといった操作が可能です。


Chrome ブラウザの GIF イメージ。カーソルが、Chrome アドレスバーの右側にあるダウンロード トレイを開いています。ダウンロード トレイには、進行中のファイルのダウンロードが表示されています。ダウンロードを一時停止するインライン オプションも提供されています。カーソルが一時停止ボタンをクリックすると、ボタンが再生ボタンに変わります。カーソルが再生ボタンをクリックすると、ダウンロードが再開されます。


新しいダウンロード エクスペリエンスは、オンラインで人々の安全を保つことにどう貢献しますか？

私たちがいつも重視しているのは、ファイルをダウンロードする際の安全性です。マルウェアやウィルスの可能性がある場合、Chrome は今後も明確な警告を表示し続け、デバイスやアカウントを守ります。実際に、Chrome の新しいダウンロード エクスペリエンスでは、スペースが広くなり、UI も柔軟になっているので、悪意のある可能性のあるファイルからユーザーを保護するために提供できる情報が増え、高度なディープ スキャン オプションも実現できるようになっています。これは、以前にはできなかったことです。詳しくは、近日公開予定の Google セキュリティ ブログをご覧ください。

ダウンロードの警告だけではありません。ダウンロード トレイは、Chrome のアドレスバーの横の決まった位置に表示されるので、信頼できるブラウザの UI とウェブ コンテンツを明確に分離するうえで役立ちます。これは、今回の刷新でどうしても実現したかった点でした。


ダウンロード トレイを拡大した Chrome ブラウザのイメージ アセット。危険なファイルのダウンロードがブロックされたことを示す通知が表示されています。


新しいダウンロード エクスペリエンスに簡単に移行できるようにする方法として、どのようなことを考えましたか？

重要なことは、Chrome の新しいダウンロード エクスペリエンスで、以前の機能をすべて利用できるようにすることでした。 たとえば、今後も新しいダウンロード トレイから、ダウンロードしたファイルを別のフォルダやプログラム、ウェブサイトにドラッグしたり、「常に開く」などのアクションを行ったりできます。ダウンロードのさらに詳しい表示も、引き続き可能になっています。ダウンロード トレイの [ すべてのダウンロードを表示 ] オプションを選択するか、Chrome のその他メニューから [ ダウンロード ] をクリックするか、Chrome のアドレスバーに chrome://downloads と入力します。

また、初期の試験運用でのフィードバックを真摯に受け止め、ダウンロード トレイを開く頻度を調整するなどの変更を加えています。Chrome の設定から、自動でトレイを開かないようにすることもできます。


Chrome ブラウザの [ダウンロード] 設定メニューのイメージ。ダウンロードが完了したときに、ダウンロードの表示を無効にするオプションを選択できます。



デベロッパーの対応が必要になることはありますか？

デベロッパーの皆さんにぜひお願いしたいのは、ユーザーのダウンロード操作をサポートするためにガイドやビジュアルを作成している場合、それを更新することです。まずは、Google Chrome ヘルプセンターのトピック、ファイルをダウンロードするを参照することを検討できるでしょう。

拡張機能デベロッパーの皆さんは、chrome.downloads 拡張機能 API の変更に注意してください。拡張機能の更新が必要になるかもしれません。具体的には、setShelfEnabled が setUiOptions に置き換えられ、新しいダウンロード エクスペリエンスの表示、非表示を切り替えられるようになっています。

公開されたばかりの新機能ですが、ぜひ使ってみてください！今後のリリースでは、ウェブからファイルをダウンロードする際の安全性を保ちながら、Chrome の生産性を維持できるように、引き続きこの機能を強化していきます。
Posted by Eiji Kitamura - Developer Relations Team

この記事は  Chrome セキュリティ チーム、Chrome Trusty Transport、David Adrian、Serena Chen、Joe DeBlasio、Emily Stark、Emanuel von Zezschwitz、その他のメンバーによる Chromium Blog の記事 "An Update on the Lock Icon" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

編集者のメモ: 業界の調査（Chrome などの）と HTTPS の普及を鑑み、Chrome のアドレスバーの鍵アイコンを新しい「調整」アイコンに置き換える予定です。これには、デフォルトで安全な状態であるべきという点を強調する、そしてサイトの設定にアクセスしやすくするという 2 つの狙いがあります。長年にわたるこの取り組みについて、以下をお読みください。

HTTPS でサイトが読み込まれるとブラウザに鍵アイコンが表示されるのは、1990 年代の Netscape の初期バージョンから続いている伝統です。Chrome はこの 10 年間にわたって、HTTPS の採用を増やし、ウェブをデフォルトで安全な場所にするための大規模な取り組みに参加してきました。2013 年時点では、Alexa のトップ 100 万サイトのうち、HTTPS をサポートしていたのはわずか 14% でした。しかし、現在は HTTPS が標準となっており、Windows 版 Chrome で読み込まれているページの 95% 以上が HTTPS を使った安全なチャネルを経由しています。これはエコシステムにとってうれしいニュースであるとともに、ブラウザでセキュリティ保護を知らせる方法を再評価する機会でもあります。中でも特に重要なのが、鍵アイコンです。

鍵アイコンは、ネットワーク接続がブラウザとサイトの間の安全なチャネルであり、サードパーティがネットワーク接続を改ざんしたり盗聴したりできないことを示すためのものです。しかしこれは、HTTPS が一般的ではなかった時代の名残でもあります。もともと HTTPS はかなり珍しいものだったことから、ある時点で Internet Explorer は、接続が HTTPS によって保護されていることを通知するアラートをポップアップ表示するようになりました。これは、ザ・シンプソンズの「万事問題なし」アラームを連想させます。HTTPS が珍しかった時代、鍵アイコンには HTTPS によって追加の保護が提供されていることをアピールするという役割がありました。しかし今は、すでに状況が変わっています。HTTPS は例外ではなく標準となり、Chrome もしかるべく進化してきました。

たとえば、鍵アイコンはウェブサイトの信頼性を表すものではありません。調査の結果、多くのユーザーが鍵アイコンを誤解していることがわかったため、2016 年にこのアイコンのデザインを変更しました。しかし、努力を尽くしたにもかかわらず、2021年の調査では、鍵アイコンの意味を正確に理解していたのは調査対象者の 11% だけでした。この誤解は無害なものではありません。ほぼすべてのフィッシングサイトでは HTTPS を使用しているため、鍵アイコンも表示されています。この誤解は広く浸透しているため、FBI を含む多くの組織が、鍵アイコンはウェブサイトの安全性を示すものではないというガイドを明確に打ち出しています。

調査で Chrome の UI を表示すると、ユーザーは南京錠を見て架空の e コマースサイトの信頼性を評価していました。実験の参加者にサイト コントロールを表示し、この状況で役立つと思われる情報を示すように求めました。これは、そのときのクリック パターンをヒートマップにしてオーバーレイ表示したものです。
現在の鍵アイコンは、Chrome のサイト コントロールの便利な入口になっています。2021 年には、Chrome の鍵アイコンの代わりに、セキュリティを連想させないサイト コントロールの入口を表示する実験についてお知らせしました。HTTP が安全でないことを示す表示は、URL バーに残しました。すると、ユーザーがサイト コントロールを開く回数が増え、大幅に UI を変更したときに起こりがちな戸惑いも見られませんでした。


現在の鍵アイコンからアクセスできるサイト コントロール。

他の団体も含めた調査結果と、HTTPS への移行が普及していることを踏まえて、Chrome の鍵アイコンを調整アイコンのようなものに置き換える予定です。次のような調整アイコンを考えています。
  • 「信頼できる」ことを連想させない
  • クリックできることが明らかである
  • 一般的な設定などのコントロールを連想させる
鍵アイコンを、コントロールや設定を示すときに一般的に使われる調整アイコンのようなものに置き換える予定です。

鍵アイコンをニュートラルなインジケーターに置き換えることで、鍵アイコンがページの信頼性を表す

という誤解を防ぐとともに、Chrome がデフォルトで安全な状態であることをアピールします。また、鍵アイコンをクリックすると重要な情報やコントロールが表示されることを理解していなかったユーザーが多いことも、調査で明らかになりました。この新しいアイコンは、鍵アイコンにつきまとう誤解を防ぎつつ、権限管理やセキュリティの詳細情報に簡単にアクセスできる場所となるはずです。

新しいアイコンは、PC プラットフォーム向けの一般的なデザイン更新の一環として、2023 年 9 月上旬に公開される Chrome 117 でリリースされる予定です。接続が安全でないことを示す警告は、今後も表示されます。Chrome Canary の chrome://flags#chrome-refresh-2023 で [Chrome Refresh 2023] を有効にすると、新しい調整アイコンが表示されるようになります。ただし、これはまだ進行中や開発中の状態であり、最終版ではないことに注意してください。



同じページ コントロール、新しいアイコン。鍵アイコンは詳細な接続セキュリティ情報の入口として残りますが、トップレベルのアクセス ポイントは新しくなります。


Android の鍵アイコンも、PC 版のさまざまな変更のタイミングに合わせて変更します。iOS の鍵アイコンはタップできないため、完全に削除します。平文 HTTP が安全でないことを示す表示は、すべてのプラットフォームで今後も残ります。

HTTPS が標準になるに伴い、Chrome と幅広いセキュリティ コミュニティの両方では、鍵アイコンを置き換えることが長年の目標でした。年を追って HTTPS の採用が大きく拡大したことで、ようやくこの手順を安全に実施できるようになったことをうれしく思っています。私たちはこれからも、デフォルトで安全なウェブの実現に向けて進んでいきます。


Posted by Eiji Kitamura - Developer Relations Team

この記事は Thomas Nattestad による Chromium Blog の記事 "How WebAssembly is accelerating new web functionality" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

WebAssembly は、ウェブの新しいデベロッパー機能の作成方法を根本的に変革します。ブラウザの相互運用性を維持するため、新しいウェブ機能は厳格な標準化プロセスを経て、クロスブラウザで実装される必要があります。数十年にわたる大規模な取り組みにより、ブラウザの機能は驚くべきレベルに達していますが、この過程には時間がかかる場合があり、すべての機能をウェブに組み込まなければならないわけでもありません。これまで何年もかけて、高レベルの機能の構成要素となる低レベル機能に注力してきましたが、現在私たちは新たな夜明けを目にしており、劇的に速いペースでさまざまな機能が登場しています。

WebAssembly 

WebAssembly は、他の言語からコンパイルしたポータブルなバイトコード形式であり、最大のパフォーマンスを実現できます。デベロッパーが WebAssembly を活用すると、別のプラットフォームのライブラリや機能をウェブに移植できます。再実装は一切必要なく、高いパフォーマンスを発揮します。さらに、並列実行スレッド や Single Instruction Multiple Data（SIMD）など、CPU のパフォーマンスを最大限に活用できる高度な計算プリミティブも提供します。

ポータビリティと高パフォーマンス CPU アクセスを実現する WebAssembly が加わったことで、ウェブには低レベルの構成要素がすべてそろい、実に多様な新機能を構築できるようになりました。これらはすべて、数々の充実した機能やレンダリング手法などを備えた、ウェブ プラットフォーム全体という驚異的な土台のうえに成り立っています。

実例 

WebAssembly のおかげで実現できた新機能はたくさんありますが、1 つのブログ投稿を丸ごと使ってその一部を紹介しています。

その中には、さまざまな理由で標準プロセスを通過できなかった機能も含まれています。また、現在標準化が進行中で、さまざまなブラウザで実装が進められているものもあります。

  • Wasm 版 FFMPEG は、ウェブアプリで効率的に動画を扱えるようにします。標準化されている WebCodecs でも同じようなエンコードやデコードが可能ですが、対応ブラウザはまだ限られています。
  • WebAssembly は、Google Meet のビデオ通話の背景ぼかしに使われており、この機能に関する専用の標準提案が行われています。

この新しい開発パラダイムがもたらすメリットイテレーションの高速化

標準化と承認を経なくても機能を公開できるので、イテレーション サイクルが年単位から日単位、場合によっては時間単位にまで短縮できます。オリジン トライアルなどのアプローチを使えば、多くの試験運用を行うことはできますが、それでも週単位や月単位のイテレーションが必要になります。イテレーションの速度を変えるということは、その対象自体を抜本的に変革するということです。

機械学習などの分野は進展が速いので、標準ベースのアプローチではついていくことができません。設計が標準化を経てクロスブラウザ実装に移ったころには、すでに新たな進展があり、プロセス全体をやり直さなければならなくなってしまいます。

とは言うものの、標準化が不可欠なことも多い点は変わりません（後述のデメリットのセクションを参照）。標準化が適している場合は、当然標準化を試みる必要があります。

さまざまなブラウザをすぐにサポート

wasm はさまざまなブラウザでサポートされているので、これを使って構築した機能もすべてのブラウザですぐに動作します。機能の相互運用性とクロスブラウザ実装は、デベロッパーにとって最大の悩みです。機能を低レベルプリミティブに移行することで、この懸念の大半を解消できます。

セキュリティの向上 

この機能は厳格なセキュリティ サンドボックスがベースになっているため、ネイティブ実装された API よりも格段にセキュリティが向上します。たとえば、Flash がウェブから削除された大きな理由は、複雑なプラグインのセキュリティを十分に強化するのが難しすぎたためです。しかし、今は Flash を WebAssembly で実行でき、セキュリティの懸念の大半が解消されています。

デメリットと制限 

複雑な問題に対するあらゆる新しいソリューションと同じく、WebAssembly にもデメリットや制限がないわけではありません。その中には、仕組み的に避けられないものもあれば、有望なソリューションが存在するものもあります。

ほとんどのウェブ開発で JavaScript の代替となるものではない   

WebAssembly は JavaScript の代替ではなく、JavaScript が時代遅れになるわけでもありません。どちらかというと、WebAssembly は JavaScript の機能を拡張するものです。

WebAssembly は JavaScript を使わずにブラウザで動作させることはできません。また、他のウェブ機能にアクセスする場合は、JavaScript のインターフェースを通す必要があります。WebAssembly で実現するライブラリや新機能は、JavaScript API を介して使用されます。wasm モジュール同士の通信や、Web API との直接インターフェースも提案されていますが、これはまだ開発の初期段階です。 ページのバンドルサイズ

ユーザーランドに移動するロジックや機能が増えることで、ページのサイズも増大します。バンドルサイズの縮小は優れたユーザー エクスペリエンスにとって最重要なので、これは大きな問題になります。そのため、この機能を使ってバンドルサイズを肥大化させる前に、慎重に検討する必要があります。この点は、小さな e コマースやブログのサイトよりも、大型のウェブアプリで問題になる可能性があります。JavaScript を多用するフレームワークでも、これが長いこと問題になっています。この状況を改善するため、さまざまなソリューションが考えられるかもしれません。

問題を軽減できる可能性があるもう 1 つの手段は、ユーザーランドの人気機能に注目し、それを参考にして、どの機能を標準化してブラウザ自体に含めるかを判断するというものです。ユーザーランドで実績を積んだ機能なら、ブラウザに自信と確証を持って搭載することができます。そのため、標準と実装にまつわる作業も大幅に簡素化されます。WebCodecs は wasm でコンパイルした FFMPEG を、手書き認識 API は wasm でコンパイルしたバージョンを置き換えるものですが、これらはその好例となります。 デバイスの機能へのアクセス 

WebAssembly などのプリミティブは、ほとんどが計算メカニズムであり、OS やデバイス自体にシステムのルート権限でアクセスする機能は一切提供されていません。ハードウェア アクセス（USB や Bluetooth）、画面やウインドウの管理、入力コントロール、ファイル システム、クリップボードなどの機能にアクセスする場合は、今後もプラットフォーム レベルの API が必要になります。Chromium の Fugu プロジェクトは、Chromium ベースのブラウザでこれらのすべての事例を実現しようとするものですが、他のブラウザでの実装も必要になります。

まとめ 

WebAssembly は、すでにブラウザの新機能実現に活用されていますが、それ以上に、根本的に新しい方法で機能の開発方法にアプローチします。何かを改善する最善の方法は、その改善方法を改善することです。すると、2 次曲線的な成長を遂げることができます。どのような新しいパラダイムにもメリットとデメリットがあります。しかし、総合的に見れば、WebAssembly は、あらゆるブラウザとデベロッパーにとって新しいアプローチであると言えます。これを使って皆さんとともに開発を進めていくのが楽しみでなりません。



Posted by Eiji Kitamura - Developer Relations Team

この記事は 、François Doray による Chromium Blog の記事 "Do more with Chrome on a single charge on MacBooks" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



Chrome は誕生当初より、効率よく動作するように設計されています。効率がよいとは、単にページをできる限り高速に読み込むことだけでなく、できる限り少ないリソースを使うことを指します。今回の速さと好奇心の投稿では、Mac のバッテリー駆動時間をできる限り延ばすために行った Chrome の改善に注目します。この改善により、ブラウズや動画の視聴をこれまで以上に長く楽しめるようになっています。 


Chrome の最新リリースでは、内部的にたくさんの最適化をし、MacBook の 1 度の充電でできることを増やしています。私たちのテストによれば、MacBook Pro（13 インチ、M2、2022）で 17 時間のブラウズまたは 18 時間の YouTube 視聴が可能です。Chrome の省エネモードをオンにすると、バッテリーでブラウズできる時間がさらに 30 分延びます（1）。私たちは、最新のハードウェアを使っている方だけでなく、すべてのユーザーのことを深く考えています。そのため、古いモデルでもパフォーマンスが向上します。 


以下では、行った変更のいくつかについて詳しく説明します。
 
iframe の微調整

iframe には数秒しか存在しないものが多いことがわかりました。そこで、最近作成された iframe について、ガベージ コレクションとメモリ圧縮ヒューリスティックスを微調整しました。その結果、短期的なメモリ使用量を抑えることができ、消費電力が減少しました（長期的なメモリ使用量には影響しません）。



タイマーの調整 

Javascript のタイマーは、ウェブの黎明期に導入されたものです。その後、ウェブ デベロッパーは、さらに効率的で同じ結果（またはそれよりも優れた結果）を実現できる API を利用できるようになっています。それでも、Javascript のタイマーはウェブページの電力消費の大部分を占めています。そこで、Chrome でのタイマーの呼び出し方法を調整し、CPU の復帰回数を少なくしました。


同様に、必要なくなってキャンセルできるようになった内部タイマーを特定することで、タイマーが CPU を復帰させる回数を減らしました。 


データ構造の効率化

同じキーで頻繁にアクセスされるデータ構造があることがわかったため、そのアクセス パターンを最適化しました。



不要な再描画の回避

ボットを使って実際のサイトを開き、ドキュメント オブジェクト モデル（DOM）の変化パターンのうち、画面上のピクセルに影響しないものを特定しました。こういったパターンを早い段階で検出し、不要なスタイル、レイアウト、描画、ラスタライズ、GPU の操作を省略するように Chrome を変更しました。Chrome UI の変化についても同じ最適化を行っています。

私たちの作業に終わりはありません。2023 年以降は、オープンソース ベンチマーク スイートによって、幅広い開発コミュニティの力を借りて Chrome の電力消費を改善できるようになります。

___
1 2023 年 2 月に MacBook Pro（13 インチ、M2、2022、8 GB の RAM を搭載し MacOS Ventura 13.2.1 を実行）と Chrome 110.0.5481.100 を使ってテストを実施し、Google の オープンソース ベンチマーク スイートで測定したもの。



Posted by Eiji Kitamura - Developer Relations Team