letsencryptの代わりにDNSレコードを介して自己署名証明書を検証しないのはなぜですか

Question

ただ疑問に思っていました。 SSL証明書を多数使用しています。最近では、ほとんど専らletsencryptを使用しています（ありがとう！）。これらの証明書の要点は、証明書上のドメイン名の所有権の証明は、これらのドメインの下でDNSレコードまたはWebサイトのいずれかを操作する権限から得られることです。 DNSの証明は、いくつかのキー（letsencryptによって与えられる）をTXTレコードとしてDNSに追加することで得られます。

それで、ドメインのDNSレコードを変更できる十分な証拠がある場合は、DNSのフィンガープリントで自己署名証明書を使用してみませんか？

これは、letsencrypt（および他のCA）のDNSベースの手順とまったく同じ量の信頼を与えると思います。

自己署名CAを作成します（さまざまな方法の手順に従ってください）
一部のドメインの証明書を作成します
手順2の証明書に手順1のCAで署名します。これで、信頼されていないCAによって署名された基本的な証明書が作成されました。
TXT（または専用）レコードを各ドメインのDNSに追加して、次のように記述します。このCAでこのドメインの証明書に署名しました。例： 'CA = -fingerpint of CA-'
ブラウザーは証明書をダウンロードし、CA/CA証明書のフィンガープリントを指定されたドメインのDNS内のデータと比較することにより、証明書を検証します。

これにより、基本的なSSL証明書と同じ信頼レベルで、第三者の干渉なしに信頼できる自己署名証明書を作成できるようになります。 DNSにアクセスできる限り、証明書は有効です。暗号化のようなDNSSECを追加して、CAとSOAレコードからハッシュを作成し、DNSレコードの変更時に信頼が失われるようにすることもできます。

これは以前に考慮されたことがありますか？

ジェルマー

Sebastian Schrader · Answer

これを可能にする基本的なインフラストラクチャが存在し、名前付きエンティティのDNSベースの認証（DANE）と呼ばれ、 RFC6698 で指定されています。これは、TLSAリソースレコードを使用して機能し、チェーン内のエンドエンティティまたはそのCAの証明書またはその公開キーを指定します（実際には4つの異なるタイプがあります。詳細はRFCを参照してください）。

可決

しかし、DANEはまだ広く採用されていません。 VeriSignは DNSSECおよびDANEの採用および時間の経過に伴うその成長を追跡を監視します：

比較のために、VeriSignによると、約270万のDNSゾーンが存在するため、すべてのゾーンの1％を少し超える数が少なくとも1つのTLSAレコードを持っています。

私は権威ある答えを出すことはできませんが、なぜDANEですか？

DANEには、証明書失効リスト（CRL）およびオンライン証明書ステータスプロトコル（OCSP）と同じ問題があります。提示された証明書の有効性を確認するには、第三者に連絡する必要があります。 HannoBöck 良い概要を示します、これが実際に大きな問題である理由。結局のところ、第三者に連絡できない場合の対処方法の問題です。この場合、ブラウザーベンダーはsoft-fail（別名：許可）を選択しましたが、全体がかなり無意味になり、Chromeが最終的に決定しました2012年にOCSPを無効にします。

DNSSEC

間違いなく、DNSはCAのCRLおよびOCSPサーバーよりもはるかに優れた可用性を提供しますが、それでもオフライン検証は不可能です。さらに、DANEはDNSSECと組み合わせてのみ使用する必要があります。通常のDNSは認証されていないUDP上で動作するため、偽造やMITM攻撃などが発生しやすくなります。DNSSECの採用は、DANEの採用よりもはるかに優れていますが、ユビキタス化にはほど遠いものです。

DNSSECを使用すると、ソフトフェイル問題に再び遭遇します。私の知る限りでは、主要なサーバー/クライアントオペレーティングシステムは、デフォルトで検証DNSSECリゾルバーを提供していません。

次に、失効の問題もあります。 DNSSECには失効メカニズムがなく、代わりに有効期間の短いキーを使用します。

ソフトウェアサポート

参加するすべてのソフトウェアは、DANEサポートを実装する必要があります。

理論的には、これは暗号ライブラリの仕事であり、アプリケーション開発者はそれほど多くのことをする必要はないだろうと思うかもしれませんが、実際、暗号ライブラリは通常プリミティブのみを提供し、アプリケーションは多くの構成とセットアップを自分で行う必要があります（そして、残念ながら物事を間違える多くの方法があります）。

たとえば、主要なWebサーバー（Apacheやnginxなど）がDANEを実装している、または実装する計画があることは知りません。 Webサーバーは、ここでは特に重要です。なぜなら、Webテクノロジーに基づいて構築されるものが増えており、そのため、多くの場合、物事が実装される最初のサーバーです。

CRL、OCSP、およびOCSP Staplingを比較として見ると、DANEの採用ストーリーがどのように進むかを推測できる可能性があります。 OpenSSL、libnss、GnuTLSなどを使用する一部のアプリケーションのみがこれらの機能をサポートしています。 Apacheやnginxのような主要なソフトウェアがそれをサポートするのにしばらく時間がかかり、再びHannoBöckの記事を参照しましたが、彼らはそれを誤解し、実装に欠陥があります。 PostfixやDovecotなどの他の主要なソフトウェアプロジェクト OCSPをサポートしないであり、CRL機能が非常に制限されており、基本的にはファイルシステム内のファイルを指します（必ずしも定期的に再読み取りされるわけではないため、サーバーを手動でリロードする必要があるなど）。これらはTLSを頻繁に使用するプロジェクトであることを覚えておいてください。次に、例えばPostgreSQL/MySQLのようにTLSがあまり一般的ではないものを検討し始めることができます。

だから私は最近のウェブサーバーでさえそれを実装していませんし、他のほとんどのソフトウェアはOCSPとCRLを実装することさえできていません。

潜在的なアプリケーション

では、実際にDANEをどこで使用できますか？現在のところ、一般的なインターネットでは利用できません。サーバーとクライアントを制御している場合は、そのオプションかもしれませんが、この場合、公開キーの固定に頼ることができます。

メールスペースでは、SMTPがどの種類の認証済みトランスポート暗号化も長い間持っていなかったため、DANEはある程度の注目を集めています。 SMTPサーバーは相互にTLSを使用することがありましたが、証明書の名前が実際に一致することを確認せず、DANEを介してこれを確認し始めています。

H&#229;kan Lindqvist · Answer

さまざまなタイプの証明書検証手順

通常のCA署名付き証明書には、いくつかのレベルの証明書検証があります。

ドメイン検証（DV）
ドメイン名の所有権のみが検証され、ドメイン名のみが証明書に「件名」として表示されます
組織検証（OV）
ドメイン名と所有者名が検証され、ドメイン名と所有者名が証明書で「件名」として表示されます
拡張検証（EV）
所有者エンティティ、ドメイン名、所有者名のより厳密な検証は、証明書では「件名」として表示され、所有者名が緑色のバーに表示されます

あなたが説明し、その代わりを提案するプロセスは、最下位レベルのドメイン検証（DV）にのみ適用されます。

DVは、LetsEncryptが行ったことなど、検証が比較的簡単に自動化できるレベルであり、トラストアンカーの唯一のソースとして使用された場合にDNSが提供できるものと同様のレベルの信頼を提供します（UIの意味、証明書は信頼されているが、検証されていない追加データが含まれている）。

名前付きエンティティのDNSベースの認証（DANE）

[〜＃〜] dane [〜＃〜] DNSSECの上に構築され（DNSデータの信頼性が重要であるため）、DNSでTLSクライアントのトラストアンカー情報を公開します。

これはTLSA RRタイプを使用し、エンドエンティティまたはCAの証明書または公開キー（selector）を識別するために使用できます。または、成功するために通常の証明書チェーン検証を必要とせずに（cert usage）、および証明書/キーデータがレコード内でどのように表されるか（一致するタイプ）。

TLSAレコードの所有者名には、ポートとプロトコルを示す接頭辞（例：_443._tcp）があり、RDataは、証明書/キーデータに加えて、cert usage、selectorおよびmatching typeモードを示します。一致。これらのパラメータの詳細については、 RFC6698のセクション2.1 を参照してください。

TLSAレコードは、たとえば次のようになります。

_443._tcp.www.example.com. IN TLSA 2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

使用モード2または3（TLSAトラストアンカーのみの使用を示す）では、DANE対応クライアントは、一般的に信頼されているCAによって署名されていないが、TLSAレコードに一致する証明書を受け入れます。。
これは概念的に、質問で提案するものと同じです。

キャッチ？ DANEを認識するクライアントは現在、ほぼ存在していません。1つの問題は、DNSSEC自体がDANEの離陸に必要なものほど広く展開されていない（特にクライアントマシンでの検証）ことです。 DANEは、認証されたDNSデータに依存する最初の潜在的に大きな新しいユースケースの1つであることを考えると、鶏と卵の問題のようです。

DNSSECとDANEの検証を追加するブラウザープラグインがありますが、この時点でメインストリームの近くにあるものはそれほど多くありません。また、ネイティブでサポートされるのではなくプラグインであるため、一般的な使用に関しては、何よりも概念実証として機能します。

それは可能でした。検討されています。それはまだ起こるかもしれませんが、多くの動きはありませんでした。