Improve DNS security for apps and servers

ハイライト

Apple サイバーセキュリティチームの Qiaoyu Deng が、DNS セキュリティの基本的な問題と、iOS 16/macOS Ventura の 2 つの解決策、DNSSEC (DNS セキュリティ拡張機能) と DDR (DNS 検出メカニズム) について説明します。

主要内容

HTTPS リクエストは安全に見えます。

ユーザーがドメイン名を入力すると、アプリが TLS 接続を確立し、サーバー証明書が検証に合格し、後続のすべてのデータが暗号化されます。問題は前のステップにあります。接続を開始する前に、システムはまず DNS を使用してドメイン名を IP アドレスに解決する必要があります。

このステップには長らく 2 つの能力が欠けていました。

まず、従来の DNS 応答は認証されません。攻撃者がリゾルバーに間違ったアドレスをキャッシュさせることを許可すると、クライアントは悪意のあるホストに接続する可能性があります。次に、従来の DNS クエリは暗号化されません。ネットワーク上の監視者は、ユーザーがどのドメイン名をクエリしたかを確認できます。

このセッションでは 2 つのパスが提供されます。DNSSEC は、DNS 応答をデジタル署名で認証し、「アドレスの信頼性」の問題を解決します。DDR (Discovery of Designed Resolver、指定リゾルバーの検出) を使用すると、デバイスが同じネットワーク上の暗号化された DNS リゾルバーを自動的に検出できるため、「クエリプロセスがバイパスされて監視されるか?」という問題が解決されます。

詳細

DNSSEC が最初に認証を解決します

(03:39) iOS 16 と macOS Ventura は、クライアント側の DNSSEC 検証のサポートを開始します。DNSSEC は、DNS 応答にデジタル署名を追加します。応答が改ざんされている場合、署名は一致できず、クライアントは応答を破棄する可能性があります。

DNSSEC も「存在しない」ことを証明します。たとえば、NSEC レコードがスピーチで使用されます。A.org、C.org、E.org、NSEC記録が証明できるD.org存在すべきではなく、攻撃者が嘘をつかないことも証明されますA.org存在しません。

より完全な検証は信頼の連鎖に依存します。クライアントは、ターゲットドメイン名のアドレス、署名、キーから開始して、ルートに到達するまで親ゾーンを段階的にクエリします。ルートトラストアンカーはデバイスにプリインストールされています。ルートキーのハッシュが事前にインストールされたアンカーと一致する限り、クライアントはターゲット IP アドレスからルートへの信頼を確立できます。

有効にする前にドメイン名インフラストラクチャを確認してください

(07:45) Apple は明確に 2 つの前提条件を与えています。

まず、ドメイン名が IPv6 をサポートしている必要があります。IPv6 のみの環境では、IPv4 のみのアドレスは合成 IPv6 アドレスに変換されます。署名付きドメイン名の場合、合成アドレスは DNSSEC 検証に失敗します。その結果、DNSSEC が有効になっていると、これらのアドレスに到達できなくなります。

次に、DNS サービスプロバイダーは DNSSEC を使用してドメイン名に署名する必要があります。アプリが DNSSEC を必要とするが、ドメイン名が署名されていない場合、ユーザーは認証の利点を得ることができず、DNS トラフィックが増加し、解決時間が長くなるだけです。

したがって、DNSSEC は、最初にクライアント上でやみくもに有効にするのには適していません。アプリ、ドメイン名、DNS サービスプロバイダーを同時に準備する必要があります。

URLSession のセッションレベルで DNSSEC を要求する

(09:01) 一連のリクエストがすべて、自分が制御する署名付きの IPv6 対応ドメイン名に接続されている場合、次のことができます。URLSessionConfigurationDNSSECを一律に有効にします。

let configuration = URLSessionConfiguration.default
configuration.requiresDNSSECValidation = true
let session = URLSession(configuration: configuration)

キーポイント:

行 1 はデフォルトを作成しますURLSessionConfiguration。
2行目requiresDNSSECValidationに設定true、DNSSEC 検証を完了するには、このセッションによって発行されたリクエストが必要です。
行 3 は構成を変更して作成されますURLSession。

この設定は、このセッションから作成されたすべての URL リクエストに影響します。適切な API ドメインがすでに DNSSEC とともにデプロイされており、リクエストのセット全体で認定されたアドレスを使用する必要があるとします。

単一の URLRequest で DNSSEC を要求する

(09:38) より厳格な DNS 認証が必要なリクエストが少数の場合は、その要件を次のように入力できます。URLRequest優れた。

var request = URLRequest(url: URL(string: "https://www.example.org")!)
request.requiresDNSSECValidation = true
let (data, response) = try await URLSession.shared.data(for: request)

キーポイント:

行 1 は、ターゲットドメイン名へのポインタを作成します。URLRequest。
行 2 は、このリクエストに対してのみ DNSSEC 検証をオンにします。
ライン 3 の用途URLSession.shared.data(for:)リクエストをしてください。

講演では、このセッションタスクはDNSSEC検証が完了した後にのみ開始されると説明された。この粒度は、ログイン、支払い、デバイス登録などのいくつかの主要なリクエストに適しており、既存のネットワーク層を段階的に移行する場合にも適しています。

Network.framework 接続で DNSSEC を要求する

(10:08) アプリが Network.framework を直接使用する場合、次のことができます。NWParameters同じ要件をオンにします。

let parameters = NWParameters.tls
parameters.requiresDNSSECValidation = true
let connection = NWConnection(host: "www.example.org", port: .https, using: parameters)

キーポイント:

行 1 は、NWParameters。
行 2 では DNSSEC 検証が必要です。
行 3 は、これらのパラメータを使用してターゲットホストと HTTPS ポートへのリンクを作成します。NWConnection。

接続が開始された後、DNSSEC 検証が完了し、システムが検証された IP アドレスに接続するまで、接続は準備完了状態になりません。DNSSEC を有効にすると、システムは検証に合格したアドレスのみを使用して接続を確立します。

DNSSEC が失敗した場合に専用のエラーを返しません。

(10:46) DNSSEC には、HTTPS とは異なる障害モデルがあります。HTTPS エラーは API 経由で報告されます。DNSSEC 検証が失敗した場合、システムは「DNSSEC 検証に失敗しました」というエラーを返しません。

検証に失敗した応答を受信することは、応答を受信しないことと同じです。

DNS プロバイダーが応答を改ざんした場合、アドレスは認証チェックに合格せず、直接破棄されます。デバイスが改ざんされた応答を持たない別のネットワークに接続すると、解像度は自動的に復元されます。

プレゼンテーションでは、いくつかの障害の原因が列挙されていました。DNS 応答が変更されていました。デバイスは事前にインストールされたトラストアンカーに到達できなかったため、トラストチェーンを確立できませんでした。ネットワークは、DNSSEC に必要なプロトコル (DNSS over TCP や DNSSEC 有効化ビットを備えた EDNS0 オプションなど) をサポートしていませんでした。署名されたドメイン名が IPv6 をサポートしていないため、合成 IPv6 アドレスの検証が失敗しました。

DDR は暗号化された DNS を自動的に有効にします

(13:09) DNSSEC は認証を解決しますが、DNS クエリ自体は依然としてクリアテキストである可能性があります。iOS 14 と macOS Big Sur はすでに暗号化された DNS を提供しています。NEDNSSettingsManager、またはプロフィールでDNSSettings、システムレベルの暗号化されたDNSを手動で構成します。あなたも使うことができますNWParametersの上PrivacyContextアプリに暗号化された DNS を選択させます。

(13:47) 新しい自動パスが iOS 16 と macOS Ventura に追加されました。現在のネットワークが DDR をサポートしている場合、DNS クエリは自動的に TLS または HTTPS を使用します。

デバイスが新しいネットワークに参加すると、_dns.resolver.arpaサービスバインディングクエリを開始します。DDR をサポートする DNS サーバーは 1 つ以上の構成を返します。次に、デバイスはこの情報を使用して、指定されたリゾルバーへの暗号化された接続を確立します。

デバイスは、暗号化されていないリゾルバーの IP アドレスが、指定されたリゾルバーの TLS 証明書に含まれている必要があることも検証します。これにより、暗号化されていないパーサーと暗号化されたパーサーが同じエンティティに属していることが確認されます。認証後、デバイスはデフォルトで暗号化された DNS を使用します。

DDR は、現在の単一ネットワークでのみ有効です。現在のネットワークが暗号化 DNS をサポートしている場合にのみ、デバイスは暗号化 DNS を自動的に使用します。また、プレゼンテーションでは、DNS サーバーの IP アドレスがプライベート IP アドレスの場合、そのようなアドレスは TLS 証明書に含めることができず、所有権を検証できないため、DDR が機能しないことも指摘しました。

エンタープライズ暗号化 DNS はクライアント認証を使用できます

(16:32) iOS 16 と macOS Ventura は、暗号化された DNS 構成でのクライアント認証の指定もサポートしています。入り口は、NEDNSSettingsManagerまたはDNSSettings profile。

エンタープライズ環境では、DNS サーバーはアクセスを許可する前にクライアントの ID を検証する必要がある場合があります。通行可能になりましたNEDNSSettingsのidentityReferenceプロパティはクライアント証明書を構成します。この講演では、これを VPN のクライアント証明書に例え、DNS over TLS と DNS over HTTPS の両方に適用されると説明しています。

重要ポイント

1. DNSSEC スイッチを主要な API リクエストに追加します

対処方法: まず、ログイン、支払い、デバイスバインドなどの主要なリクエストのみを保護します。
実行する価値がある理由:URLRequest.requiresDNSSECValidationネットワーク層全体が一度に変更されることを避けるために、影響範囲を 1 つのリクエストに制限できます。
開始方法: ドメイン名が IPv6 をサポートしており、DNS サービスプロバイダーによって DNSSEC 署名が完了していることを確認します。次に、これらのリクエストでURLRequestに開くrequiresDNSSECValidation。

2. 独自の API ドメイン名について DNSSEC 事前チェックを行う

対処方法: 公開する前に、ドメインが署名されており、IPv6 をサポートしているかどうかを確認してください。
実行する価値がある理由: この講演では、署名のないドメイン名は追加の DNS トラフィックと長い解決時間をもたらし、合成アドレスが検証できないため、IPv4 のみのドメイン名は IPv6 のみのネットワークでは到達できなくなることを明確に指摘しました。
開始方法: ドメイン名の署名ステータスと IPv6 レコードをサービスのオンラインチェックリストに組み込み、アプリ側で DNSSEC を有効にするかどうかを決定します。

3. Network.framework クライアントで DNSSEC 要件をバインドする

内容: 自社構築の長時間接続、リアルタイム通信、またはカスタムプロトコル接続には、認定アドレスの使用が必要です。
実行する価値がある理由:NWParameters.requiresDNSSECValidationさせますNWConnectionDNSSEC チェックサムと接続の確立が完了した後にのみ、準備完了状態になります。
開始方法: 作成するNWParameters.tls、設定requiresDNSSECValidation = true、このパラメータを使用してNWConnection。

4. エンタープライズネットワークの DDR およびクライアント証明書を計画する

対処方法: 企業ネットワーク内のデバイスが暗号化された DNS に自動的に切り替わり、DNS サーバーがクライアントの ID を検証できるようにします。
価値がある理由: DDR を使用すると、デバイスは DNS over TLS または DNS over HTTPS 構成を自動的に検出できます。identityReferenceクライアント証明書は暗号化された DNS 用に構成できます。
開始方法: ネットワーク側のサポート_dns.resolver.arpaサービスバインディングクエリ。設定側で使用されるNEDNSSettingsManagerまたはDNSSettingsプロファイルは、暗号化された DNS とクライアント証明書の構成を提供します。

Improve DNS security for apps and servers

ハイライト

主要内容

詳細

DNSSEC が最初に認証を解決します

有効にする前にドメイン名インフラストラクチャを確認してください

URLSession のセッションレベルで DNSSEC を要求する

単一の URLRequest で DNSSEC を要求する

Network.framework 接続で DNSSEC を要求する

DNSSEC が失敗した場合に専用のエラーを返しません。

DDR は暗号化された DNS を自動的に有効にします

エンタープライズ暗号化 DNS はクライアント認証を使用できます

重要ポイント

1. DNSSEC スイッチを主要な API リクエストに追加します

2. 独自の API ドメイン名について DNSSEC 事前チェックを行う

3. Network.framework クライアントで DNSSEC 要件をバインドする

4. エンタープライズネットワークの DDR およびクライアント証明書を計画する

関連セッション

コメント

ハイライト

主要内容

詳細

DNSSEC が最初に認証を解決します

有効にする前にドメイン名インフラストラクチャを確認してください

URLSession のセッション レベルで DNSSEC を要求する

単一の URLRequest で DNSSEC を要求する

Network.framework 接続で DNSSEC を要求する

DNSSEC が失敗した場合に専用のエラーを返しません。

DDR は暗号化された DNS を自動的に有効にします

エンタープライズ暗号化 DNS はクライアント認証を使用できます

重要ポイント

1. DNSSEC スイッチを主要な API リクエストに追加します

2. 独自の API ドメイン名について DNSSEC 事前チェックを行う

3. Network.framework クライアントで DNSSEC 要件をバインドする

4. エンタープライズ ネットワークの DDR およびクライアント証明書を計画する

関連セッション

コメント

URLSession のセッションレベルで DNSSEC を要求する

4. エンタープライズネットワークの DDR およびクライアント証明書を計画する