ACMEプロトコルのDNSレコードに基づくドメイン所有権検証の自動化の提供

翻訳者から ：これはEFFの記事の翻訳です

技術の詳細：ACME DNSチャレンジ検証の自動化の確保 。

オリジナル記事の著者：Joona Hoikkala。

初版発行日：2018年2月23日



今月初め、 Let's Encrypt （2年前にEFFが立ち上げを支援した無料の自動化されたオープン認証機関）は、 5000万を超えるアクティブな証明書を発行するという重要なマイルストーンを超えました。 また、Let's Encryptは数週間以内に、多くのシステム管理者が要求したワイルドカード証明書の発行も開始するため、この数は増え続けます。

ワイルドカード証明書とは何ですか？

HTTPS証明書を確認するために、ユーザーのブラウザは、証明書にWebサイトのドメイン名が実際に示されているかどうかを確認します。 たとえば、 www.eff.orgの証明書には、実際にはwww.eff.orgをこの証明書の有効なドメインとして含める必要があります。 所有者がすべてのドメインに対して1つの証明書を使用する場合、証明書には複数のドメイン（ www.eff.org 、ssd.eff.org、sec.eff.orgなど）を含めることもできます。



ワイルドカード証明書は、すべてを明示的にリストするのではなく、「このドメイン内のすべてのサブドメインに対して有効です」と記載された証明書です。 （これは、アスタリスクで示されるワイルドカード文字を使用して証明書に示されます。したがって、現在eff.orgの証明書を確認すると、* .eff.orgに対して有効であると表示されます。）したがって、システム管理者はすべての証明書を取得できますドメインを作成し、証明書を受け取ったときに考えもしなかった新しいサブドメインで使用します。



ワイルドカード証明書を発行するには、Let's Encryptは、 www.eff.orgなどのドメイン名をIPアドレスに変換するドメインネームシステムであるDNSに基づくチャレンジを使用して、ドメイン制御を確認するようユーザーに要求します69.50.232.54。 Let's Encryptなどの証明機関の観点からは、ドメインの管理はDNSの基礎の1つであるため、DNSレコードを変更するよりも、ドメインを管理することを証明するより良い方法はありません。



ただし、Let's Encryptの重要なアイデアの1つは、証明書の取得は自動プロセスであるということです。 しかし、それを自動化するには、証明書を要求するソフトウェアもこのドメインのDNSレコードを変更できる必要があります。 この機能を実現するために、ソフトウェアはDNSサービスの資格情報（ログイン、パスワード、暗号化トークンなど）にもアクセスできる必要があり、これらの資格情報は証明書が自動的に取得される場所に保存する必要があります。



多くの場合、これは受信プロセスを処理するマシンが危険にさらされた場合、DNSクレデンシャルでも同じことが起こることを意味し、これが本当の危険です。 この投稿の残りの部分では、このプロセスに関係するコンポーネント、およびどのオプションがそれをより安全にするかについて詳しく説明します。

ドメイン所有権の検証はどのように機能しますか？

高レベルでは、ドメイン所有権チェックは、ACMEプロトコルの一部である他のすべての自動チェックと同様に機能します。Let's Encryptなどの認証機関（CA）やCertbotなどのクライアントソフトウェアが情報の交換に使用できるプロトコルサーバーが要求している証明書、およびサーバーが対応するドメイン名の所有権を確認する方法。



ドメイン所有権の検証中、ユーザーは、このタイプの検証をサポートするCertbotなどのACMEクライアントソフトウェアを使用して、CAに証明書を要求します。 クライアントが証明書を要求すると、CAは特定のTXTレコードをDNSゾーンに追加することにより、ドメインの所有権の証明をクライアントに要求します。 詳細：CAは一意のランダムトークンをACMEクライアントに送信し、ドメインを制御するユーザーは、このトークンをそのドメインの「_acme-challenge」という名前の定義済みサブドメインのDNSゾーンにTXTレコードとして配置する必要があります。ユーザーが証明しようとしています。



たとえば、* .eff.orgのドメインを検証しようとしている場合、検証サブドメインは「_acme-challenge.eff.org」になります。 トークン値がDNSゾーンに追加されると、クライアントは所有権チェックを続行するようにCAに指示します。その後、CAはドメインの権限のあるサーバーでDNSクエリを実行します。 権限のあるDNSサーバーが正しい所有権検証トークンを含むDNSレコードで応答する場合、ドメインの所有権が証明され、証明書の発行プロセスを続行できます。

DNSサービスはデジタルIDを制御します

DNSゾーンに関連する脅威は非常に危険なため、ユーザーのブラウザは、ドメインにアクセスしようとするときに連絡するIPアドレスを知るためにDNSを信頼しています。 これは、電子メールからWebサービスまで、ドメインの下で解決可能な名前を使用するすべてのサービスに適用されます。



DNSが侵害されると、攻撃者は電子メールまたはその他の安全なサービスに向けられたすべての接続を簡単に傍受し、TLSの暗号化を停止し（ドメインの所有権を確認し、それらの有効な証明書を取得できるため）、データを解読してそれらを読み取ることができます。その後、データを再暗号化し、サーバーに転送します。 ほとんどの人にとって、検出は非常に困難です。

個別の限定的な特権

厳密に言えば、ACMEクライアントが自動モードで更新を行うためには、このクライアントは_acme-challengeサブドメインのTXTレコードを更新できる資格情報のみにアクセスできる必要があります。 残念ながら、ほとんどのDNSソフトウェア製品およびDNSサービスプロバイダーは、これらの特権を制限する詳細なアクセス制御を提供していないか、主要なDNSゾーンの更新またはトランザクション以外でこれを自動化するAPIを提供していません。 これにより、可能な自動化方法が不適切または安全になりません。



そのような制限を乗り越えるのに役立つ簡単な方法があります： CNAMEレコードを使用します。 CNAMEレコードは、本質的に別のDNSレコードへのリンクとして機能します。 Let's EncryptはCNAMEレコードチェーンに従い、チェーンの最後のレコードの所有権検証トークンを有効にします。

問題を軽減する方法

CNAMEレコードを使用しても、主な問題は、ACMEクライアントがDNSレコードの変更を許可する資格情報にアクセスする必要があることです。 この根本的な問題を軽減するさまざまな方法があり、さまざまなレベルの難易度と、セキュリティ侵害が発生した場合のセキュリティへの影響があります。



次のセクションでは、この投稿では、これらの方法の一部を紹介し、資格情報が侵害された場合に考えられる結果を説明します。 1つの例外を除き、すべてCNAMEレコードを使用します。

TXTレコードの更新のみを許可する

最初の方法は、TXTレコードを更新できる特権を持つ資格情報セットを作成することです。



侵害された場合、この方法は、DNS資格情報を使用して独自の証明書を取得できるため、攻撃者がDNSゾーン内のすべてのドメインに対して証明書を発行でき、メール配信を中断できるという結果に制限されます。 メール配信への影響は、メール固有のTXTレコード、つまりSPF 、 DKIM、およびその拡張機能ADSPおよびDMARCから生じます。 それらの侵害は、侵害されたドメインからの送信者を装ったフィッシングメールの配信も促進します。

「スローアウェイ」確認ドメインを使用する

2番目の方法は、_acme-challengeサブドメインのCNAMEレコードを手動で作成し、別の資格情報セットによって制御されるゾーンにある検証ドメインを指すことです。



たとえば、「yourdomain.tld」と「 www.yourdomain.tld 」をカバーする証明書を取得する場合は、「_ acme-challenge.yourdomain.tld」と「_acme-challenge.www.yourdomain」という2つのCNAMEレコードを作成する必要があります。 .tld "-また、検証のために外部ドメインをポイントします。 所有権を確認するために使用されるドメインは、外部DNSゾーンまたはサブバンドDNSゾーンに存在する必要があります。サブゾーンDNSゾーンには、管理用の独自の資格情報セットがあります。 （サブデリゲートのDNSゾーンはNSレコードを使用して定義され、ゾーンの一部に対する完全な制御を外部ソースに効果的に委任します。）



この方法の妥協効果は非常に限られています。 実際に保存された資格情報は外部DNSゾーンのものであるため、資格情報を受け取った攻撃者は、このゾーンのレコードを指すすべてのドメインに対してのみ証明書を発行できます。 ただし、実際にどのドメインを指しているかを把握するのは簡単です。攻撃者は証明書の透過性ログを読み取り、これらの証明書のドメインに脆弱なDNSゾーンを指すマジックサブドメインがあるかどうかを確認するだけです。

DNSゾーンへの制限されたアクセス

ソフトウェアまたはDNSプロバイダーでサブドメインに関連付けられたアクセス許可（粒度の高い特権）を作成できる場合、これは問題全体を軽減するのに役立ちます。



残念ながら、公開時点で、これらの特権を提供する唯一のプロバイダーが見つかりました-これはMicrosoft Azure DNSです。 Dynにはきめ細かな特権もあると思われますが、「レコードの更新」以外にサービスで低い特権レベルを見つけることができなかったため、ゾーンは完全に脆弱なままです。



Route53などのユーザーは、ユーザーがサブデリゲートゾーン、新しいユーザー資格情報を作成し、新しいゾーンのNSレコードを示し、CNAMEレコードを使用して_acme-challenge検証サブドメインを指定できるようにします。 所有権チェックを使用する必要のあるドメインごとにこれらすべての手順を実行する必要があるため、この方法を使用して権限を正しく配布するには多くの作業が必要です。

ACME-DNSを使用する

免責事項：以下で説明するソフトウェアは著者によって作成されたもので（元の記事-約翻訳者）、DNSを介したドメイン所有権の検証を安全な方法で自動化するために必要な資格情報を効率的に管理するために必要な機能の例として使用されます。



最後の方法は、ACME-DNSと呼ばれるソフトウェアで、議論中の問題に特に対処するために書かれており、完全に排除できます。 唯一の欠点は、この方法では、サポートが必要なインフラストラクチャに別のコンポーネントが追加され、インターネットへのパブリックアクセスのためにDNSポート（53）を開く必要があることです。



ACME-DNSは、HTTP APIが制限された単純なDNSサーバーとして機能します。 API自体では、自動的に生成されたランダムなサブドメインのTXTレコードのみを更新できます。 失われた資格情報を要求したり、他のエントリを更新または追加したりする方法はありません。 次の2つのエンドポイントを提供します。

• / register-このエンドポイントは、使用する新しいサブドメインを作成し、その後にユーザー名とパスワードを作成します。 オプションのパラメーターとして、登録エンドポイントはホワイトアップデートのCIDR範囲のリストを受け入れます。
• / update-このエンドポイントは、サーバー上の現在のドメイン所有権チェックトークンを更新するために使用されます。

ACME-DNSを使用するには、最初にA / AAAAレコードを作成し、それをNSレコードにポイントして委任ノードを作成する必要があります。 その後、エンドポイント/レジスタを介して新しい資格情報セットを作成し、ソースゾーンの確認確認「_acme-challenge」のサブドメインから新しく作成されたサブドメインへのCNAMEレコードをポイントします。



ローカルに保存される唯一の資格情報はACME-DNS用であり、フィールド内のドメインの検証サブドメインの正確なTXTレコードを更新する場合にのみ有効です。 これにより、攻撃者に対する潜在的な侵害の影響を、これらのドメインの証明書を発行する能力に効果的に制限します。



ACME-DNSの詳細については、以下を参照してください。

github.com/joohoi/acme-dns

おわりに

ACME DNSを介したドメイン所有権検証の問題を解決するために、ACME IETFワーキンググループのAssisted-DNSなどの提案が議論されましたが、これらの問題はまだ解決されていません。 侵害の影響を制限する唯一の方法は、特定のTXTレコードを変更するためにDNSゾーンアカウントのアクセス権を制限することなので、ドメイン所有権検証の自動化の信頼できる実装の現在の可能性はわずかです。



唯一の持続可能なオプションは、DNSソフトウェアとサービスプロバイダーに、より小さなゾーン資格情報を作成する方法を実装するか、この特定のユースケースにまったく新しいタイプの資格情報を提供することです。