Subscribe to receive notifications of new posts:

次世代型プライバシー保護プロトコルの構築を支援

2020-12-08

8 min read

この10年間、Cloudflareはインターネットインフラストラクチャにおける重要な役割を担い、WebサイトやAPI、Webサービスがより安全で効率的になるように支援してきました。インターネットの成長は、その容量やユーザー数だけにとどまらず、デザインや機能性の面でも進化を遂げています。インターネットエコシステムの一員であるCloudflareは、インターネットがユーザーを尊重し、ユーザーに価値を提供できるインターネットの未来を構築する責任を担っています。今日は、世界中のお客様やインターネットユーザーにとって重要なもの、つまりプライバシーに関して、インターネットプロトコルの改善に役立つ、いくつかの発表を行います。

今回発表する技術は次のとおりです。

  • HTTPSにおける最新の情報漏えいをくい止めるーEncrypted Client Hello(ECH)(旧https://blog.cloudflare.com/encrypted-sni/暗号化SNI)
  • DNSをさらにプライベートなものにするOblivious DNS-over-HTTPS (ODoH)の使用
  • パスワード認証のための優れたプロトコル、OPAQUEの開発によるパスワード漏えいの防止

これらのプロジェクトはそれぞれ、私たちのオンライン生活とデジタルフットプリントを左右するインターネットの一側面に影響を与えるものです。それを知っているかどうかにかかわらず、オンラインには私たち自身と私たちの生活に関する多くの個人情報があります。こうした情報を守るために、当社ができることがあります。

この1 年で、IETFなどの標準化団体を通じて、インターネットテクノロジーの大手 (Mozilla、Google、Equinix など) と提携し、これらの新しいプライバシー保護プロトコルをインターネット規模で設計、デプロイ、テストしてきました。これら3つのプロトコルが採用されることに伴い、オンライン生活で重大な部分に影響を与え、オンラインプライバシーの真の改善に役立つことを期待しています。

Cloudflareで受け継がれる伝統

より良いインターネットを構築する技術をサポートし、開発することが、Cloudflareの使命の中核です。業界は、インターネットをより安全かつ堅牢なものにするために、目覚ましい進化を遂げ、当社もこれに尽力してきました。長年にわたりさまざまな活動を通じて、この進歩に少しでも貢献できたことを誇りに思っています。

重要なものをいくつかご紹介しましょう。

  • Universal SSL。当社はWebの暗号化に率先して取り組んできました。2014年にUniversal SSLを立ち上げて以来、Webサイトの暗号化をお客様に無料で提供し、Let's Encryptなどの認証機関、Webブラウザ、Webサイト運営者に働きかけ、協働して、混合コンテンツを減らすよう尽力してきました。Universal SSLがローンチされ、Cloudflareのお客様全員に無料でHTTPSの提供が開始される以前は、Webサイト接続の30%しか暗号化されていませんでした。業界の努力により、今では80%が暗号化され、インターネットトラフィック全体に対する暗号化の割合は、はるかに大きくなっています。また、Webの暗号化に取り組む他にも、証明書透明性プロジェクトへの支援を行ってきました。このプロジェクトは、 NimbusMerkle Townを経由して行われ、HTTPSが信頼に値することを示す証明書エコシステムの説明責任を向上させました。
  • TLS 1.3 と QUIC 。当社はまた、既存のセキュリティプロトコルのアップグレードを支持し続けてきました。HTTPSを保護する基盤となるプロトコルであるTransport Layer Security(トランスポート層セキュリティ)(TLS)について見てみましょう。Cloudflareのエンジニアは、標準の最新バージョンであるTLS 1.3の設計に貢献し 、2016年にプロトコルの初期バージョンのサポートを開始しました。この初期の展開は、プロトコルの最終バージョンの改善に役立ちました。TLS 1.3は現在Web上で最も広く使用されている暗号化プロトコルであり、当社が早期に採用した、新しいQUIC規格の主要コンポーネントでもあります。
  • ルーティング、名前、時間のセキュリティ保護  。当社は、インターネットの他の重要なコンポーネントの安全化に尽力してきました。RPKIツールキット、測定調査、、「Is BGP Safe Yet(BGPは安全か)」ツールを通じてルーティングのセキュリティを確保する当社の取り組みは、破壊的なルート漏えいに対するインターネットのレジリエンスを大幅に向上させました。当社のタイムサービス(time.cloudflare.com)は、ユーザーの時計と、NTSやRoughtimeのようなより安全なプロトコルとを同期させるのに役立っています。また、1.1.1.1でのDNS-over-HTTPSおよびDNS-over-TLSのローンチをサポートし、権威DNSサービスとRegistrarで、ワンクリックDNSSECをサポートすることで、DNSをよりセキュアにしました。

信頼に値するシステムのセキュリティをオンラインで改善し続けることは、インターネットの成長にとって極めて重要です。しかし、より根本的な原理となるのが敬意を払うということです。インターネットの基盤となるインフラストラクチャは、ユーザーを尊重した設計にする必要があります。

ユーザーを尊重するインターネットの構築

プライバシーポリシーが適用されている、特定のWebサイト、または、サービスにサインインすると、そのサイトがデータに対して何を行うかがわかります。明確に示されるからです。

ユーザーとインターネットの運営者の間には、そのような合意はありません。ユーザーは、インターネットサービスプロバイダー (ISP) や、アクセス先のサイトとは、合意が成立している可能性がありますが、ユーザーが、データがどのネットワークを通過するかまで把握している可能性は低いのではないでしょうか。多くの人は、インターネットについて、画面に表示されるものから先のことは想像がつかないはずです。ですから、 トランジットホールセラーミドルボックスの検査がそもそも何を意味していて、これらの例えからプライバシーポリシーとは何かを理解するのは難しいでしょう。

暗号化がなければ、ネットワーク間で情報が送信される際に、インターネットのブラウジング情報は、数え切れないほどたくさんの第三者とオンラインで暗黙的に共有されてしまいます。安全なルーティングがなければ、ユーザーのトラフィックはハイジャックされ、中断される可能性があります。プライバシー保護プロトコルがなければ、ユーザーのオンライン生活は、彼らが考えている程(または期待する程)プライベートなものではありません。インターネットのインフラストラクチャは、ユーザーとその期待を尊重するようには構築されていないのです。

図:ネットワーク上でのトラフィックの動き、ルートに漏えいがある場合と、漏えいがない場合

朗報とも言えるのは、インターネットは常に進化しているということです。インターネットの進化をサポートする一団体であるインターネットアーキテクチャ委員会(IAB)は、インターネットの主要な標準化機関であるインターネット技術特別調査委員会(IETF)においてアーキテクチャの監督を行っています。IABは最近、インターネットプロトコルを設計する際にエンドユーザーが優先順位付けされるべきであるとの記載があるRFC 8890 を公開しました。ここでは、エンドユーザーの利益とサービスプロバイダー、企業、または政府の利益の間に矛盾がある場合、IETFの決定はエンドユーザーを優先すべきであるとの記述があります。エンドユーザーの主要な利益の1つはプライバシーの権利であることから、IABはインターネットプロトコルがプライバシーをどのように考慮すべきかを示すために、RFC 6973を公開しました。

本日の技術的なブログ記事は、 ユーザーのプライバシーを尊重するためのインターネットの改善に関するものです 。プライバシーは複数の分野にまたがる複雑なトピックであるため、「プライバシーの向上」が何を意味するかを明確にすることが重要です。ここでは特に、インターネット上で公開されている個人情報(機密情報)を処理するプロトコルを変更し、このデータを閲覧できる人数を制限する方法について具体的に説明します。このデータは引き続き存在しますが、インターネットスタックの上位層、つまりアプリケーション層で収集するメカニズムを構築しない限り、サードパーティが利用したり、閲覧することはできません。

これらの変更は、Webサイトの暗号化にとどまらず 、インターネットの基盤となるシステムの設計にも深く関連するものです。

ツールボックス:暗号化とセキュアなプロキシ

データを見ることなくそれが使用できることを確認する2つのツールは、暗号化とセキュアなプロキシです。

暗号化により、非常に限られたユーザーだけ(キーを持つユーザー)が情報を理解できる形に変えることができます。暗号化を、データのセキュリティ上の問題をキーの管理問題に変換するツールと説明することもあります。これは滑稽ですが、正しい説明です。暗号化すれば、キーを持つユーザーのみがデータを閲覧できるため、プライバシーに関して考えることも簡単になります。

データへのアクセスを保護するもう1つの主なツールは、分離とセグメント化です。

データにアクセスできる当事者を物理的に制限することで、効果的にプライバシーウォール(壁)を構築できます。一般的なアーキテクチャは、ポリシー対応のプロキシを頼って、データをある場所から別の場所に移動することです。このようなプロキシは、プライバシーポリシーの規定に従って、機密データを削除したり、データ転送をブロックするように設定できます。

これらのツールはどちらも効果的ですが、組み合わせるとさらに効果が高まります。オニオンルーティング(Torの基盤となる暗号化技術)は、プロキシと暗号化を併用して、強力なプライバシーを徹底する方法の一例です。大まかに言えば、AがBにデータを送信する場合、Bのキーを使用してデータを暗号化し、プロキシのキーでメタデータを暗号化してプロキシに送信できます。

インターネット上に構築されたプラットフォームとサービスは、ユーザーインターフェイスを通じて提示されるプライバシーポリシーのように、許諾システム内に構築することができます。インターネットのインフラストラクチャは、プロトコルの基盤となるレイヤーに依存しており、インターネットのこれらのレイヤーは、ユーザーと交流する場所からは遠く離れているため、ユーザーの同意という概念を構築することはほぼ不可能です。ユーザーを尊重し、プライバシーの問題からユーザーを保護するために、インターネットを集結させるプロトコルは、デフォルトでプライバシーを有効にして設計する必要があります。

データ vsメタデータ

ほとんど暗号化されていないWebから、暗号化されたWebへの移行は、エンドユーザーのプライバシーのために多くのことを行っています。たとえば、「 コーヒーショップストーカー」は、ほとんどのサイトで問題ではなくなりました。大半のサイトにオンラインでアクセスする際、ユーザーは、Webブラウジング体験のあらゆる側面(検索クエリ、ブラウザのバージョン、認証Cookieなど)をインターネット経由で他の誰かに覗き見られることはありません。サイトが適切に構成され、HTTPSを使用している場合、ユーザーは自分のデータが第三者に覗き見られることなく、意図した当事者のみに送ることができることを知っています。なぜなら、ユーザーの接続は暗号化され、認証が必要だからです。

ただし、HTTPS では、Webリクエストの内容のみが保護されます  。HTTPS経由でサイトを閲覧しているだけであっても、閲覧パターンのプライバシーを保てるというわけではありません。これは、HTTPS が交換の重要な側面、つまり、メタデータの暗号化に失敗するためです。電話にたとえるならば、電話の会話の内容ではなく、電話番号自体がメタデータです。つまり、メタデータとは、データの中身ではなく、データに関する情報のデータを指します。

なぜそれが重要なのか、その違いを説明するために、ここでは図を使って解説します。これはWebサイトを訪れるとき、なにが起きているのかを説明する図です。たとえば <embarassing>.comでホストされている画像が埋め込まれている次のページに移動するとします(https://< imageboard > .com/room101/ )。

点線で囲った部分は、データを転送する必要があるインターネットの一部を表します。これに該当するのは、ローカルエリアネットワークやコーヒーショップ、ユーザーのインターネットサービスプロバイダー(ISP)、インターネット中継プロバイダー、サーバーをホストするクラウドプロバイダーのネットワーク部分などです。ユーザーは多くの場合、こうしたプロバイダーやネットワークと何の関係も持たず、こうしたプロバイダーなどがユーザーのデータを使ってなにかをすることを防止するための契約も持っていません。これらの関係者がデータを見ないとしても、インターネットトラフィックを傍受しようとする物が上手く介入できれば、暗号化されずに送信されたデータはすべて覗き見ることができてしまいます。こうしたプロバイダーなどが、ユーザーデータについてなにも見ないことが一番良いのです。

この例では、ユーザーが<imageboard>.comを訪れたという事実は、それを目にした人にわかってしまいますし、訪れたことを推測できます。しかし、ページコンテンツが暗号化されていたとしても、ユーザーがどのページにアクセスしたかについて、知ることができます。なぜなら、<embarassing>.comもまた、誰の目にも見える状態だからです。

一般ルールとして、インターネット上でデータがオンパスパーティ(データを送受信する者)にアクセスできる状態なら、誰かがこのデータにアクセスするものです。また、オンパスパーティは、このデータの転送を容易にするため、メタデータを必要としていることも事実です。このバランスをどのように取るかについては、RFC 8558で検討されています。ここでは、メタデータの多さ(プライバシーにとって悪い)とメタデータの少なさ(オペレーションにとって悪い)とのバランスを考慮してプロトコルがどのように慎重に設計されるべきかを説明しています。

理想的には、プロトコルは最小特権という原則で設計されるべきなのです。オンパスパーティ(パイプの役目をする)がデータを適切な場所に転送するために必要な最小限の情報を提供し、それ以外のものはデフォルトで機密に保つ必要があります。TLS 1.3およびQUICを含む現在のプロトコルは、この理想への実現に向けての重要なステップですが、メタデータを非公開に保つということに関しては十分ではありません。

「自分が誰なのか」と、「オンラインでの行動」の両方を知ることは、プロフィールにつながる

今日の発表は、2つのレベルのメタデータ保護を反映するものです。1 つ目は、サードパーティオブザーバー(ISPなど)が使用できるメタデータの量を制限し、もう1つは、ユーザーがサービスプロバイダーと共有するメタデータの量を制限することです。

ホスト名は、第三者の目から保護する必要があるメタデータの例です。これを、DoHとECHが行おうとしています。ただし、訪問しているサイトからホスト名を非表示にするわけにはいきません。また、DNSのようなディレクトリサービスにホスト名を隠すというわけにもいきません。DNSサーバーは、リゾルバーとして、解決するホスト名を把握する必要があるのです!

プライバシーの問題は、サービスプロバイダーが、訪問先サイトと訪問者が誰であるかという両方についての知識を持ち合わせている場合に発生します。個々のWebサイトには、このような危険な情報の組み合わせはありませんが(ブラウザですぐに消去される、サードパーティーCookieを除く)、DNSプロバイダーにはこの危険な情報の組み合わせがあるのです。ありがたいことに、DNSリゾルバーが実際に、訪問先のサービスのホスト名と、どのIPから来ているかの必ずしも「両方」を知っておく必要はありません。 ODoHの目標である、2つを切り離しておくことは 、プライバシーにとっては良いことなのです。

インターネットは「Cloudflareの」インフラストラクチャの一つです

道路はよく舗装され、照明設備を整え、正確な標識を設置し、最適な状態で接続されているべきです。また、車内に誰がいるかを基準にして車を止めるように設計されてはいません。あるいは、そうすべきではないのです!交通インフラストラクチャと同様に、インターネットインフラストラクチャには、必要な場所にデータを取得する責任がありますが、パケットの内部を調べて判断することはしません。しかし、インターネットはコンピュータとソフトウェアでできており、ソフトウェアは利用可能なデータに基づいて決定を下すように書かれる傾向があります。

プライバシー保護プロトコルは、インフラストラクチャプロバイダーやその他の者が内部を覗き、個人データに基づいて意思決定を行う誘惑を排除しようとします。HTTPのようなプライバシーを保護しないプロトコルは、個人データと、パスワード、IPアドレス、ホスト名などのメタデータを「明示的な」データとしてインターネット経由で送信します。明示的であるということは、目にした人が収集し、何らかの行動をすることが可能だということです。HTTPSのようなプロトコルは、暗号化を使用して一部のデータ(パスワードやサイトコンテンツなど)をネットワーク上で非表示にすることで、これを改善します。

本日ご紹介する3つのプロトコルは、この概念を拡張するものです。

  • ECHは、暗号化されていないメタデータのほとんどをTLS(ホスト名を含む)から取得し、事前に取得しておいたキーで暗号化します。
  • ODoH(AppleとCloudflareが共同で開発したDoHの新しいサービス)は、プロキシとオニオン(タマネギ)のような暗号化を使用して、DNSクエリーの発信元をDNSリゾルバーから見えないようにします。これにより、ホスト名を解決する際にユーザーのIPアドレスが保護されます。
  • OPAQUEは、新しい暗号化技術を使用して、パスワードをサーバー側からも非表示の状態に保ちます。(プライバシーパスに見られるように)紛失擬似ランダム関数と呼ばれる構造を使用すると、サーバーはパスワードを知らされることなく、ユーザーがパスワードを知っているかどうかだけがわかります。

インターネットインフラストラクチャをより物理的なインフラストラクチャのように機能させることで、ユーザーのプライバシーをより簡単に保護できるのです。ユーザーが収集に同意する機会がある場合にのみ個人データを収集できる場合、インターネットはよりプライベートになります。

共に活動する

インターネットをよりプライベートにする新しい方法でみてきたように、世界規模でのイノベーションは単独では実現しません。これらのプロジェクトは、IETFやIRTFのような組織で、さまざまな人々が結集してオープンに行われた共同作業なのです。重要なのは、プロトコルがコンセンサスプロセスを通じて生じることです。このコンセンサスにはインターネットの基盤である相互につながるシステムを構成する者すべてが関与します。ブラウザビルダーから、暗号技術者、DNSオペレーター、Webサイト管理者まで、これは本当にグローバルなチームの取り組みの成せる技なのです。

また、Cloudflareは、インターネットへの技術的な変化が必然的に技術コミュニティを超えた影響をもたらすことも認識しています。これらの新しいプロトコルを採用することは、法的および政策にも影響を与える可能性があります。当社は政府や市民社会団体と協力して、これらの潜在的な変化の影響についての教育を支援しています。

ここで、この成果について共有できることをうれしく思います。そして、より多くの方々がこうしたプロトコルの開発に参加してくれることを楽しみにしています。今日発表するプロジェクトは、学界、産業界、愛好家から成る専門家が一丸となって設計し、Cloudflareの研究エンジニア(インターンの仕事もここに含まれることを強調しておきます)、Cloudflareのすべての人の支援を受けて構築されたものです。

もしこのような仕事に関わってみたい、と思われましたら、ぜひお問い合わせください。絶賛人員拡大中です!

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
日本語DoH (JP)DNS (JP)Encrypted SNI (JP)Encryption (JP)Privacy (JP)Privacy Week (JP)TLS (JP)

Follow on X

Nick Sullivan|@grittygrease
Cloudflare|@cloudflare

Related posts

July 16, 2024 1:00 PM

2024年第2四半期インターネットの混乱のまとめ

2024年第2四半期には、政府指示による遮断とケーブル切断がいずれも、インターネット障害の大きな原因となりました。この記事では、これらの混乱だけでなく、停電、メンテナンス、技術的問題、軍事行動、未知の原因によって引き起こされる他の混乱についても探求します...

July 11, 2024 5:00 PM

アプリケーションセキュリティレポート:2024年最新版

インターネットサイバーセキュリティの動向に関するCloudflareの2024年最新版。グローバルトラフィックの洞察、ボットトラフィックの洞察、APIトラフィックの洞察、クライアント側のリスクなどについても言及しています...

July 04, 2024 1:00 PM

2024年6月27日に発生したCloudflare 1.1.1.1のインシデント

2024年6月27日、世界中で一部の小数ユーザーが、1.1.1.1に到達不能または性能が低下していることに気付いた方もいるのではないかと思います。本現象の根本的な原因は、BGP(ボーダーゲートウェイプロトコル)ハイジャックとルートリークの組み合わせによるものでした...