9. セキュリティに関する考慮事項
9.1. ポートの変更
代替サービスを使用することは、少なくとも代替ポート上のオリジンのリソースにアクセスすることを意味します。したがって、代替サービスを注入して通知されたポートでリッスンできる攻撃者は、オリジンを乗っ取ることができます。特定のサーバーでは、ユーザーが共有ポートで利用可能ないくつかの個人的なページを制御でき、権限の低いポートでリクエストを受け入れることも正常です。
例えば、一部のページに HTTP レスポンスヘッダーフィールドを追加できる攻撃者は、Alt-Svc ヘッダーフィールドを使用して、オリジン全体のトラフィックを同じホスト上の別のポートにリダイレクトできます。そのポートが攻撃者の制御下にある場合、攻撃者は HTTP サーバーを装うことができます。
このリスクは、セクション 2.1 の要件によって軽減されます。
サーバー上では、代替サービスを通知する機能を制限し、そのホストでリッスンするためにポートを開くことができるユーザーを制限することによっても、このリスクを軽減できます。
9.2. ホストの変更
代替サービスの使用によりホストが変更されると、攻撃者がオリジンへの通信を乗っ取る機会が生じます。
例えば、攻撃者がそれを代替サービスとして正常に関連付けることによって、"innocent.example.org" へのすべてのトラフィックを "evil.example.com" に送信するようにユーザーエージェントに納得させることができれば、攻撃者はそのオリジンを装うことができます。これはローカルで（セクション 9.1 の軽減策を参照）、またはリモートで（例えば、中間者攻撃として仲介者によって）行うことができます。
これが、クライアントが代替サービスがオリジン全体の制御下にあり、有効であるという合理的な保証を持たなければならないというセクション 2.1 の要件の理由です。例えば、オリジンの証明書を提示することは、代替サービスがオリジンのトラフィックを提供する権限があることを証明します。
この保証は、代替サービスの認証に使用される方法と同じくらい強力でしかないことに注意してください。特に、TLS 認証を使用してそうする場合、攻撃者の証明書を正当であるように見せるためのよく知られたエクスプロイトがあります。
代替サービスを使用して、そのような攻撃を持続させることができます。例えば、仲介者は、ターゲットへの TLS で保護された通信を中間者攻撃し、すべてのトラフィックを新鮮度寿命の長い代替サービスに誘導することができます。これにより、ユーザーエージェントは仲介者を使用していない場合でも、攻撃者にトラフィックを誘導し続けます。
実装は、オリジンへの直接接続と同様に、代替サービスに対しても証明書のピン留め検証（[RFC7469] など）を実行しなければなりません（MUST）。実装は、どの証明書が代替サービスに受け入れられるかについて、他の要件を追加することを選択する場合があります。
9.3. プロトコルの変更
代替サービスの使用により ALPN プロトコルが変更されると、プロトコル識別子自体がこれを意味するため、オリジンへの新しい接続のセキュリティプロパティは、オリジンへの「通常の」接続のセキュリティプロパティとは異なる可能性があります。
例えば、"https://" URI が、ある形式のエンドツーエンド暗号化（おそらく TLS）を使用しないプロトコルを通知している場合、これは URI スキームが意味するセキュリティへの期待に違反します。したがって、クライアントは代替サービスを盲目的に使用することはできず、代わりに提示されたオプションを評価して、仕様、実装、およびエンドユーザーのセキュリティ要件と期待が満たされていることを確認します。
9.4. 代替サービスを使用したクライアントの追跡
代替サービスを選択することは、サーバーが提供する新しいホスト名に接続することを意味します。一意の名前を使用することで、サーバーはクライアントのリクエストを追跡できる可能性があります。そのような追跡は、"persist" フラグが使用されている場合、複数のネットワークにわたってユーザーを追跡する可能性があります。
リクエストの相関を防ぎたいクライアントは、相関が許可されていない複数のリクエストに対して代替サービスを使用しないことを決定できます。
ユーザーエージェントでは、オリジン固有のデータがクリアされるとき（通常はクッキー [RFC6265] がクリアされるとき）、代替サービス情報を削除しなければなりません（MUST）。
9.5. リクエストスキームに関する混乱
一部のサーバー側 HTTP アプリケーションは、接続コンテキストに基づいてセキュリティに関する仮定を行います。例えば、ポート 443 で提供されることを、"https://" URI の使用およびそれが意味するさまざまなセキュリティプロパティと同一視します。
これは、接続自体のセキュリティプロパティだけでなく、その反対側のクライアントの状態にも影響します。例えば、Web ブラウザは、プロトコル処理の目的だけでなく、多くの方法で "https://" URI を "http://" URI とは異なる方法で扱います。
代替サービスの用途の 1 つは、接続を別のプロトコルとポートに移行できるようにすることであるため、これらのアプリケーションは特定の接続のセキュリティプロパティについて混乱する可能性があり、安全なコンテキスト（"https://" URI など）を目的とした情報（例えば、クッキーやコンテンツ）を、安全なコンテキストとして扱っていないクライアントに送信してしまう可能性があります。
このリスクは、他の接続プロパティ（[RFC7540]、セクション 8.1.2.3 および [RFC7230]、セクション 5.3.2）の代わりに、セキュリティコンテキストの兆候としてプロトコルによって明示的に伝送される URI スキーム（HTTP/2 の ":scheme" や HTTP/1.1 のリクエストターゲットの「絶対形式」など）を使用することで、サーバーで軽減できます。
プロトコルがスキームを明示的に伝送しない場合（TLS 上の HTTP/1.1 の場合など）、サーバーはすべてのリクエストが安全でないコンテキストを持っていると仮定するか、安全でないスキーム（HTTP など）の代替サービスを通知することを控えることによって、このリスクを軽減できます。