マルチパスドメイン認証（Multipath Domain Control Validation）を使用した証明書発行の保護

このブログ記事は、暗号化ウィーク 2019の内容です。

インターネット上の信頼性は、公開鍵暗号基盤（PKI）に支えられています。PKIがデジタル証明書を発行することでサーバーはWebサイトをセキュアに保つことができ、暗号化された信頼できる通信の基盤を提供します。

証明書を利用する場合、証明書内の公開鍵を使用してサーバーIDを検証することにより、HTTPSの暗号化が可能になります。HTTPSは、銀行のログイン情報や個人的なメッセージなどのセンシティブデータを通信するWebサイトでは特に重要です。ありがたいことに、Google Chromeなどの最新のブラウザでは、HTTPSを使用して保護されていないWebサイトに「保護されていない通信」と表示して、ユーザーが自分がアクセスしているWebサイトのセキュリティについて意識を高めることができるようにしています。

このブログ記事では、CloudflareがCAに提供する、証明書の発行をさらに確実に保護する新しい無料ツールを紹介します。まず、詳細の説明に進む前に、証明書の発行元について説明しましょう。

認証局（CA）は、証明書の発行を担当する機関です。

任意のドメインに証明書を発行する際、CAはドメイン認証（DCV）を使用して、当該ドメインの証明書を要求するエンティティがドメインの正当な所有者であることを確認します。ドメインの所有者は、DCVを使用して次のいずれかの操作を行います。

1. ドメインのDNSリソースレコードを作成する。

2. そのドメインにあるWebサーバーにドキュメントをアップロードする。

3. ドメインの管理者用電子メールアカウントの所有権を証明する。

DCVプロセスにより、悪意のある第三者が要求元が所有していないドメインの秘密鍵と証明書の組み合わせを取得するのを防ぎます。

悪意のある第三者がこの組み合わせを取得するのを防ぐことは、非常に重要です。不適切に発行された証明書と秘密鍵の組み合わせが相手側に入手された場合、被害者のドメインになりすまして、機密性の高い HTTPSトラフィックを処理してしまう可能性があります。これは、インターネットに対する既存の信頼を損なうもので、個人データが大規模に侵害されるおそれがあります。

たとえば、CAをだましてgmail.comの証明書を誤発行させた場合、GoogleになりすましてTLSハンドシェイクを実行し、Cookieとログイン情報を取得して被害者の Gmailアカウントにアクセスできます。証明書の誤発行のリスクは明らかに深刻です。

このような攻撃を防ぐために、CAはDCVを実行した後でのみ証明書を発行します。ドメインの所有権を確認する1つの方法は、HTTP認証によるもので、これは、セキュリティ保護したいWebサーバー上の特定の HTTPエンドポイントにテキストファイルをアップロードして行います。 もう一つのDCVメソッドは、電子メールを利用するもので、検証コードへのリンクを含む電子メールを、当該ドメインの管理者の連絡先に送信する方法です。

例えば、アリスという人がドメイン名aliceswonderland.comを購入し、このドメイン専用の証明書を取得しようとしているとします。アリスは、認証局としてLet's Encryptを使用することを選択します。まず、アリスは独自の秘密鍵を生成し、証明書署名要求（CSR）を作成する必要があります。彼女はCSRをLet's Encryptに送信しますが、CAはアリスがaliceswonderland.comを所有していると確認できるまで、そのCSRの証明書と秘密鍵を発行しません。次にアリスは、HTTP認証を通じて、このドメインを所有していることを証明できます。

Let's EncryptがHTTP経由でDCVを実行する場合、アリスは、Webサイトの /.well-known/acme-challengeパスにランダムな名前の付いたファイルを配置する必要があります。CAは、http://aliceswonderland.com/.well-known/acme-challenge/<random_filename>に対してHTTP GET要求を送信して、このファイルを取得する必要があります。このエンドポイントに予期された値が存在すれば、DCVは成立します。

HTTP認証の場合、アリスはファイルをhttp://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNzにアップロードします。

ファイル本文に以下を含みます。

curl http://aliceswonderland.com/.well-known/acme-challenge/YnV0dHNz

GET /.well-known/acme-challenge/YnV0dHNz
Host: aliceswonderland.com

HTTP/1.1 200 OK
Content-Type: application/octet-stream

YnV0dHNz.TEST_CLIENT_KEY

CAは、Base64トークン YnV0dHNzを使用するように指示します。 TEST_CLIENT_KEYは、アカウントにリンクされたキーにあり、証明書の要求者とCAだけが知っています。CAは、このフィールドの組み合わせを使用して、証明書の要求者が実際に当該ドメインを所有していることを確認します。その後、アリスは自身のWebサイト用の証明書を取得することができます。

ユーザーがドメインの所有権を検証するもう 1 つの方法は、ドメインのリソースレコードにCAからの確認文字列、_トークン_を含むDNS TXTレコードを追加する方法です。たとえば、これは、Googleに対して認証を行っている企業のドメインの例です。

$ dig TXT aliceswonderland.com
aliceswonderland.com.	 28 IN TXT "google-site-verification=COanvvo4CIfihirYW6C0jGMUt2zogbE_lC6YBsfvV-U"

ここでは、アリスは特定のトークン値を持つTXT DNSリソースレコードの作成を選択しています。GoogleのCAは、このトークンの存在を確認して、アリスが本当に自分のWebサイトを所有していることを検証できます。

サーバーがクライアントと安全に通信するためには、証明書の発行が必要です。このため、証明書の発行を担当するプロセスもセキュアであることが、とても重要なのです。残念ながら、これは常に当てはまるとは限りません。

プリンストン大学の研究者が最近、一般的なDCVメソッドには、悪意のある第三者がネットワークレベルで実施する攻撃に対する脆弱性があることを発見しました。ボーダーゲートウェイプロトコル（BGP）が、インターネットの「郵便サービス」として、最も効率的なルートを介してデータを配信する責任を王とすると、自律システム（AS）は1 組織が運営するインターネットネットワークの業務を担う個々の郵便局の支店に相当します。ネットワークレベルの悪意のある第三者は、そのトラフィックにドメインの証明書のような重要な内容が含まれているような場合にBGP経由で不正なルートをアドバタイズしてトラフィックを盗もうとすることがあります。

BGPにより認証局を欺くは、DCVプロセスの間に企てられる可能性のある、悪意のある第三者が所有していないドメインの証明書を入手しようとする5種の攻撃を取り上げています。これらの攻撃を実装した後、作者は（倫理的に）、自分が所有していないドメインの証明書を下記の、上位5つのCAから取得できました。Let’s Encrypt、GoDaddy、Comodo、Symantec、GlobalSignですがどのように行ったのでしょうか？

BGPハイジャックを使用したDCVプロセスの攻撃方法には、主に次の2通りの方法があります。

1. Sub-Prefix（サブプレフィックス）攻撃

2. Equally-Specific-Prefix（等価特定プレフィックス）攻撃

これらの攻撃は、悪意のある第三者が被害者のドメインに対する証明書署名要求をCAに送信した場合の脆弱性を生みます。CAがHTTP GETリクエストを使用して（前述のように）ネットワークリソースを検証すると、悪意のある第三者はBGP攻撃を利用してトラフィックを乗っ取り、CAの要求がドメイン所有者ではなく第三者に再ルーティングします。これらの攻撃がどのように行われるかを理解するには、まず少し計算を行う必要があります。

インターネット上のすべてのデバイスは、数値による識別子としてIP（インターネットプロトコル）アドレスを使用しています。IPv6アドレスには128ビットが含まれ、スラッシュ表記の後にプレフィックスのサイズが続きます。したがってネットワークアドレス2001:DB8:1000::/48の場合、「/48」がネットワークに含まれるビット数を示します。つまり、残りの80ビットの部分にホストアドレスが含まれ、合計で10,240 個のホストアドレスがあるということになります。プレフィックス番号が小さいほど、ネットワークに残るホストアドレスが多くなります。この知識を元に、攻撃について考えていきましょう。

攻撃1：Sub-Prefix（サブプレフィックス）攻撃

BGPがルートをアナウンスするとき、ルーターは常により具体的なルートに従うことを優先します。そのため、2001:DB8::/32および2001:DB8:1000::/48がアドバタイズされた場合、ルーターはより具体的なプレフィックスの後者を使用します。このことは、悪意のある第三者が被害者のドメインのIPアドレスを使用して、特定のIPアドレスに対してBGPアナウンスを行う場合に、問題になります。被害者のleagueofentropy.comのIPアドレスが2001:DB8:1000::1で、2001:DB8::/32としてアナウンスされるとします。悪意のある第三者がプレフィックス2001:DB8:1000::/48をアナウンスした場合、被害者のトラフィックを捕らえて、_サブプレフィックスハイジャック_攻撃を開始します。

2018年4月中に発生したようなIPv4攻撃の場合は、/24と/23がアナウンスされ、より具体的な/24が不正なエンティティによってアナウンスされました。IPv6の場合は、/48 および/47のアナウンスになります。いずれのシナリオでも、/24と/48が、グローバルにルーティングできる最小のブロックです。次の図では、/47はテキサス州、/48はより具体的なテキサス州オースティンです。新しい（しかし不正な）ルートは、インターネットの一部の既存のルートを上書きしました。次に、攻撃者は、DNSレコードを持つ通常のIPアドレス上で不正なDNSサーバーを実行し、既存のサーバーの代わりに新規の不正なWebサーバーに向けます。これにより、不正なルートが伝播されていたエリア内の、犠牲者のドメインに向けられていたトラフィックが引き寄せられました。この攻撃が成功した理由は、受信側ルーターがより具体的なプレフィックスを常に優先するためです。

攻撃2：Equally-Specific-Prefix（等価特定プレフィックス）攻撃

前回の攻撃では、悪意のある第三者はより具体的なアナウンスを提供することでトラフィックをハイジャックすることができましたが、被害者のプレフィックスが/48 で、サブプレフィックス攻撃が実行可能ではない場合は、どうでしょうか？この場合、攻撃者はequally-specific-prefix（等価特定プレフィックス）ハイジャックを開始し、攻撃者は被害者と同じプレフィックスをアナウンスします。つまり、ASは、パスの長さなどのプロパティに基づいて、被害者と悪意のある第三者のアナウンスの間で優先ルートを選択します。この攻撃は、トラフィックの一部のみを傍受します。

この論文内では、より高度な攻撃についても詳細に述べられています。この攻撃は根本的には同類の攻撃ですが、もっとステルス性の高いものです。

攻撃者は、自分が所有していないドメインの偽の証明書の取得に成功すると、被害者のドメインを装って説得力のある攻撃を実行し、被害者のTLS トラフィックを復号化して傍受することができます。TLSトラフィックの復号化が可能なことで、悪意のある第三者は暗号化されたTLSトラフィックに対して中間者攻撃（MITM）を実行し、被害者のドメイン宛てのインターネットトラフィックを自分宛に再ルーティングすることができます。攻撃のステルス性を高めるために、悪意のある第三者は引き続き被害者のドメインを通じてトラフィックを転送し、検出不能な方法で攻撃を実行します。

悪意のある第三者がドメインを制御するもう 1 つの方法は、DNSネームサーバーに属する送信元IPアドレスを使用した、DNSトラフィックのスプーフィングです。誰でも自分のパケットの送信IPアドレスを変更できるため、悪意のある第三者は被害者のドメインの解決に関与するすべてのDNSネームサーバーのIPアドレスを偽装してCAに応答する際にネームサーバーを偽装できます。

これは、単にDNSの応答を改ざんしてCAを攻撃するよりも高度な攻撃です。各DNSクエリにはそれぞれランダム化されたクエリ識別子と送信元ポートがあるため、偽のDNS応答は、DNSクエリの識別子と一致しないと説得力を持ちません。これらのクエリ識別子はランダムであるため、正しい識別子を使用してスプーフィングされた応答を行うことはきわめて困難になります。

悪意のある第三者は、ユーザーデータグラムプロトコル（UDP）DNSパケットをフラグメント化して、識別するDNS応答情報（ランダムDNSクエリ識別子など）を1つのパケットで配信し、実際の回答セクションは別のパケットに続けることができます。このようにして、悪意のある第三者は正当なDNSクエリに対するDNS応答をスプーフィングします。

たとえば、悪意ある第三者が、victim.comの証明書を誤発行させるために、パケットのフラグメント化を強制し、DNS認証のスプーフィングを試みるとします。悪意のある第三者は、victim.comのDNSネームサーバーに、小さな最大転送単位または最大バイトサイズで、ICMPの「フラグメント化が必要な」パケットを送信します。こうして、DNS応答のフラグメント化を開始するネームサーバーを取得します。CAがvictim.comのTXTレコードを要求するvictim.comのDNSクエリをネームサーバーに送信すると、ネームサーバーは上記の 2 つのパケットに応答をフラグメント化します。1つ目のパケットには悪意のある第三者がスプーフィングできないクエリIDと送信元ポートが、2つ目のパケットには、悪意のある第三者がスプーフィングできる回答セクションが含まれています。悪意ある第三者は、DNS認証プロセスの間中ずっとCAに対してスプーフィング回答を送信し続け、CAがネームサーバーから実際の回答を受け取る前にスプーフィング回答を滑り込ませようとすることがあります。

その際、DNS応答の回答セクション（重要な部分）が改ざんされ、悪意のある第三者がCAをだまして証明書を誤発行させる可能性があります。

一見すると、証明書透過性ログが誤発行された証明書を公開して、CAが証明書をすばやく取り消せるようにできるようにも思えます。ただし、CTログには、新しく発行された証明書が含まれるまでに最大24時間かかる場合があり、証明書の失効は異なるブラウザー間では統一されない可能性があります。攻撃が起きてから対処するのではなく、CAが積極的に攻撃をあらかじめ防ぐことができるソリューションが必要です。

Cloudflareは、CA向けの無料APIの提供を発表します。これによりグローバルなネットワークを活用して世界中の複数のバンテージポイントからDCVを実行できます。このAPIは、BGPハイジャックおよびオフパスDNS攻撃に対してするDCVプロセスを強化します。

Cloudflareが世界中で175以上のデータセンターを運営していることから、当社は複数のバンテージポイントからDCVを実行できるという他にない立場にあります。各データセンターはDNSネームサーバーまたは HTTPエンドポイントへの固有のパスがあります。つまり、BGPルートのハイジャックが成功しても、DCVリクエストの一部にしか影響を与えず、BGPのハイジャックをさらに抑制できることを意味します。また、CloudflareではRPKIを使用しているため、実際にBGPルートに署名と検証を行っています。

このDCVチェッカーは、オフパスのDNSスプーフィング攻撃からCAを追加的に保護します。オフパスの攻撃者からの保護用に、サービスに組み込んだ新しい機能が、DNSクエリの送信元IPのランダム化です。送信元IPを攻撃者にとって予測不能にすると、DCV認証エージェントに対して偽のDNS応答の 2 番目のフラグメントをスプーフィングすることがより困難になります。

当社のDCV APIは、複数のパスから収集する複数のDCV結果を比較することで、悪意ある第三者が、実際に所有していないドメインを所有しているとCAに誤解させることはほとんど不可能になります。CAは、当社のツールを使用することにより、正当なドメイン所有者にのみ証明書を発行することを確実にできます。

CloudflareのマルチパスDCVチェッカーは、次の2つのサービスで構成されています。

1. 特定のデータセンターからのDCV実行を担当するDCVエージェント

2. CAからのマルチパスDCV要求を処理し、DCVエージェントの一部に発送するDCVオーケストレーター

CAは、傍受されることなくDCVが実施できたことを確認したい場合、実行するDCVの種類とそのパラメーターを指定して当社APIに要請できます。

続いてDCVオーケストレーターは、各要求を、異なるデータセンター内にある20を超えるDCVエージェントのうちランダムに抽出する一部に転送します。各DCVエージェントはDCVリクエストを実行し、その結果をDCVオーケストレーターに転送し、そこで各エージェントが監視した内容が集計されてCAに戻されます。

この方式を一般化すると、認証局認定（CAA）レコードなどのDNSレコードに対してマルチパスクエリを実行することもできます。CAAレコードは、CAがドメインに対して証明書を発行することを認定するため、これをスプーフィングして認定されていないCAをだまし、証明書を発行させることは、マルチパス監視が防ぐもう 1 つの攻撃方法です。

マルチパスチェッカーの開発中、BGPハイジャック攻撃を通じて証明書の誤発行の概念実証（PoC）を紹介したプリンストンの研究グループと連絡を取り合っていました。_BGPにより認証局を欺くこと_と題する論文の共同執筆者である、Prateek Mittal氏は、

「分析から、複数のバンテージポイントからドメイン認証を行うことで、局所的なBGP攻撃の影響を著しく軽減することが示されました。当社ではWebセキュリティを強化するため、すべての認証局でこのアプローチを採用することをお勧めします。Cloudflareが実装するこの防御の特に魅力的な特徴は、Cloudflareがインターネット上の膨大な数のバンテージポイントを利用可能であり、DCVの堅牢性を大幅に向上させることができる点です。」と書いています。

当社のDCVチェッカーは、インターネットの信頼性を広めるべきであるとの当社の信念に基づいて、第三者による分析（Cloudflareが提供するような）によって徹底的に吟味して、安定性とセキュリティを確保しています。このツールは、当社の既存の証明書透過性モニターをサービス一式としてまとめたものであり、CAが証明書発行の責任向上のために使用することができます。

マルチパスDCVチェッカーの構築においては、複数のCloudflare製品をドッグフーディング（試用）することができました。

シンプルな収集および集計ツールとしてのDCVオーケストレーターは、Cloudflare Workersの優秀な候補でした。こちらの記事を参考にこのオーケストレーターをTypeScriptに実装し、展開および繰り返しが容易な、型指定された信頼性の高いオーケストレーターサービスを作成しました。当社独自のDCVオーケストレーター用サーバーの維持が不要なことには、たいへん満足しています。

当社ではArgo Tunnelを使用し、Cloudflare WorkersがDCVエージェントと通信できるようにしています。Argo Tunnelを使用することで、当社のDCVエージェントをWorkers環境に容易かつセキュアに公開することができます。CloudflareにはDCVエージェントを実行するデータセンターが約175か所あるため、Argo Tunnelを通して多数のサービスを公開しており、パワーユーザーとして様々な送信元からArgo Tunnelの負荷をテストする機会がありました。Argo Tunnelは、しっかりとこの新しい送信元からの流入を処理してくれました。

個人や企業でDCVチェッカーにご興味のある方は、dcv@cloudflare.comまでお問い合わせください。当社では、皆様の証明書発行に関するセキュリティを、このマルチパスクエリや認証でいかに向上できるかについて、皆様からのご意見をお待ちしています。

新しい種類のBGPおよびIPスプーフィング攻撃は、PKIの基盤を損なう恐れがあり、Webサイトの所有者が、証明書の発行を受ける時にマルチパス検証を求めることも重要です。Cloudflareによるか、自社かに関わらず、すべてのCAでマルチパス検証を使用することをお勧めします。Let’s Encryptのテクニカルリード、Jacob Hoffman-Andrewsが、次のように書いています。

「BGPハイジャックは、Web PKIがまだ解決する必要がある大きな課題の1つであり、マルチパス検証はこの解決策の一端を担えると考えています。我々は独自に実装テストを実施し、他のCAにもマルチパスに目を向けるようお勧めしています。」

将来的には、Webサイトの所有者が、CA選択時にマルチパス検証のサポートの有無を確認するようになって欲しい、と願っています。

暗号化ウィーク Crypto 暗号化 DNS BGP