「ブラウザ用の DANE テクノロジーは失敗した」という意見がある

DNS を使用してドメイン名を認証するための DANE テクノロジーとは何か、また、それがブラウザーで広く使用されていない理由について説明します。

/スプラッシュ解除/ パリウス・ドラグナス

デーンとは

認証局 (CA) は、次のことを行う組織です。 従事している 暗号証明書 SSL証明書。 彼らは電子署名を付けて、その信憑性を確認しました。 ただし、証明書が違反で発行されるという状況が発生することがあります。 たとえば、昨年 Google は、Symantec 証明書の侵害を理由に、その証明書に対する「信頼解除手順」を開始しました (この話については、私たちのブログで詳しく説明しました - 時間 и два).

このような状況を避けるために、IETF は数年前に 開発を開始した DANE テクノロジー (ただし、ブラウザーでは広く使用されていません。なぜこれが起こったのかについては後ほど説明します)。

DANE (DNS-based Authentication of Named Entities) は、DNSSEC (Name System Security Extensions) を使用して SSL 証明書の有効性を制御できるようにする一連の仕様です。 DNSSEC は、アドレス スプーフィング攻撃を最小限に抑えるドメイン ネーム システムの拡張機能です。 これら XNUMX つのテクノロジーを使用すると、Web マスターまたはクライアントは DNS ゾーン オペレーターの XNUMX つに連絡し、使用されている証明書の有効性を確認できます。

基本的に、DANE は自己署名証明書として機能し (その信頼性を保証するのは DNSSEC)、CA の機能を補完します。

これはどう動かすのですか

DANE の仕様については、次のとおりです。 RFC6698。 文書によると、 DNSリソースレコード 新しいタイプ、TLSA が追加されました。 これには、転送される証明書、転送されるデータのサイズとタイプ、およびデータ自体に関する情報が含まれます。 ウェブマスターは証明書のデジタル拇印を作成し、DNSSEC で署名して、TLSA に配置します。

クライアントはインターネット上のサイトに接続し、その証明書を DNS オペレーターから受け取った「コピー」と比較します。 それらが一致する場合、リソースは信頼できると見なされます。

DANE wiki ページには、TCP ポート 443 での example.org への DNS リクエストの次の例が記載されています。

IN TLSA _443._tcp.example.org

答えは次のようになります。

 _443._tcp.example.com. IN TLSA (
   3 0 0 30820307308201efa003020102020... )

DANE には、TLSA 以外の DNS レコードを処理する拡張機能がいくつかあります。 XNUMX つ目は、SSH 接続でキーを検証するための SSHFP DNS レコードです。 で説明されています RFC4255, RFC6594 и RFC7479。 XNUMX 番目は、PGP を使用したキー交換用の OPENPGPKEY エントリです (RFC7929）。 最後に、XNUMX 番目は SMIMEA レコードです (標準は RFC で正式化されていません。 その草稿のみ) S/MIME を介した暗号キー交換用。

DANEの問題は何ですか

XNUMX 月中旬、DNS-OARC カンファレンスが開催されました (これは、ドメイン名システムのセキュリティ、安定性、開発を扱う非営利団体です)。 専門家がパネルディスカッションに参加 結論に達したブラウザの DANE テクノロジは (少なくとも現在の実装では) 失敗しました。 カンファレンスに出席するジェフ・ヒューストン氏、主任研究員 APNIC、XNUMX つの地域インターネット登録機関のうちの XNUMX つ、 答えた DANE を「死んだテクノロジー」として語る。

一般的なブラウザは、DANE を使用した証明書認証をサポートしていません。 市場に出ている 特別なプラグインがあります、TLSA レコードの機能とそのサポートについても明らかにします。 徐々にやめる.

ブラウザーでの DANE 配布の問題は、DNSSEC 検証プロセスの長さに関係しています。 システムは、初めてリソースに接続するときに、SSL 証明書の信頼性を確認し、DNS サーバーのチェーン全体 (ルート ゾーンからホスト ドメインまで) を通過するために暗号化計算を実行する必要があります。

/スプラッシュ解除/ ケイリー・ディクストラ

Mozilla はメカニズムを使用してこの欠点を解消しようとしました DNSSEC チェーン拡張 TLSの場合。 これは、クライアントが認証中に検索する必要がある DNS レコードの数を減らすことを目的としていました。 しかし、開発グループ内で意見の相違が生じ、解決できませんでした。 その結果、このプロジェクトは 2018 年 XNUMX 月に IETF によって承認されましたが、中止されました。

DANE の人気が低いもう XNUMX つの理由は、世界での DNSSEC の普及率が低いことです。 リソースの 19% のみが機能します。 専門家らは、これではDANEを積極的に推進するには十分ではないと感じた。

おそらく、業界は異なる方向に発展するでしょう。 市場関係者は、DNS を使用して SSL/TLS 証明書を検証する代わりに、DNS-over-TLS (DoT) および DNS-over-HTTPS (DoH) プロトコルを推進することになります。 後者については、次の記事で言及しました。 以前の資料 ハブレで。 DNS サーバーに対するユーザーのリクエストを暗号化して検証し、攻撃者によるデータのなりすましを防ぎます。 今年の初めに、DoT はすでに 実装されました パブリックDNSについてはGoogleに。 DANE に関しては、このテクノロジーが「再び鞍部に戻り」、さらに普及できるかどうかは、今後の課題です。

さらに読むべきものは次のとおりです。

IT インフラストラクチャ管理を自動化する方法 - XNUMX つのトレンドについて説明する
JMAP - 電子メールを交換する際に IMAP に代わるオープン プロトコル

アプリケーション プログラミング インターフェイスを使用して保存する方法
1cloud.ru の例を使用したクラウド サービスでの DevOps
クラウド アーキテクチャの進化 1cloud

1cloud テクニカル サポートはどのように機能しますか?
クラウド テクノロジーに関する誤解

出所： habr.com