インターネット技術タスクフォース (IETF) B. Campbell
Request for Comments: 9440 Ping Identity
カテゴリ: 情報 M. Bishop, Editor
ISSN: 2070-1721 Akamai
2023年7月

Client-Cert HTTP ヘッダーフィールド

概要

本書は、TLS 終端リバースプロキシ（TTRP）が、相互認証された TLS 接続のクライアント証明書情報をオリジンサーバーに対して共通かつ予測可能な方法で伝達することを可能にする HTTP 拡張ヘッダーフィールドについて説明します。

このメモの状態

本書はインターネット標準トラックの仕様ではなく、情報提供目的で公開されています。

本書はインターネット技術タスクフォース (IETF) の成果物です。IETF コミュニティのコンセンサスを示すものであり、公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。IESG によって承認されたすべての文書がいかなるレベルのインターネット標準の候補となるわけではありません。詳細は RFC 7841 のセクション 2 を参照してください。

本書の現行の状態、訂正情報（errata）、およびフィードバックの方法については https://www.rfc-editor.org/info/rfc9440 を参照してください。

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

1. はじめに

HTTPS アプリケーションの比較的一般的な導入パターンとして、オリジンの HTTP アプリケーションサーバーがクライアントからの TLS 接続を終端するリバースプロキシの背後に配置されることがあります。プロキシはインターネットからアクセス可能で、クライアントのリクエストをプライベートまたは保護されたネットワーク内の適切なオリジンサーバーに振り分けます。オリジンサーバーはクライアントから直接アクセスできず、リバースプロキシを介してのみ到達可能です。この種の導入のバックエンドの詳細は、プロキシサーバーに対してリクエストを行い、プロキシから発信されたかのようにレスポンスを受け取るクライアントにとって通常は不透明です。プロキシとオリジンサーバー間でも通常 HTTPS が使用されますが、クライアントが確立する HTTPS の TLS 接続はクライアント自身とリバースプロキシ間のものに限られます。

この導入パターンは、n 層アーキテクチャ、コンテンツ配信ネットワーク、アプリケーションロードバランサ、イングレスコントローラなど、様々なバリエーションで見られます。

頻繁ではないものの、TLS クライアント証明書による認証が使われることがあり、その場合オリジンサーバーはアプリケーションロジックのためにクライアント証明書の情報を必要とすることが多いです。そのようなロジックにはアクセス制御判断、監査ログ、発行されたトークンやクッキーを証明書に紐付ける処理（およびその検証）などが含まれます。必要とされる証明書からの詳細もアプリケーション要件によって異なります。これらの種類のアプリケーション導入を実際に機能させるためには、リバースプロキシがクライアント証明書に関する情報をオリジンアプリケーションサーバーに伝達する必要があります。執筆時点では、一般的な方法としては非標準フィールドに（あるエンコーディングで）証明書全体またはその一部を含めてオリジンサーバーに渡す方法が用いられています。この解決策は動作しますが、独立して開発されたコンポーネント間の相互運用性は、使用されるフィールド名や設定可能性、公開される証明書の部分、証明書のエンコード方法などの実装選択によっては面倒であるか、場合によっては不可能になることがあります。この一般的に発生する機能に対して、よく知られた予測可能なアプローチがあれば、独立実装間の相互運用性を改善・簡素化できるでしょう。

本書の範囲は、既存の実践を記述しつつ、より良く低労力な相互運用性を促進するために十分な具体的な詳細を規定することです。したがって、本書では TLS 終端リバースプロキシ（TTRP）がバックエンドのオリジンサーバーに追加する 2 つの HTTP ヘッダーフィールド "Client-Cert" と "Client-Cert-Chain" を記述します。Client-Cert フィールド値は、発端のクライアントと TTRP 間の相互認証された TLS 接続で使用されたエンドエンティティのクライアント証明書を含みます。オプションとして、Client-Cert-Chain フィールド値はエンドエンティティ証明書の検証に使用された証明書チェーンを含むことがあります。これによりバックエンドのオリジンサーバーはアプリケーションロジックでクライアント証明書情報を利用できます。TTRP とオリジンサーバー間に追加のプロキシやホップ（それらの間で相互認証された TLS 接続がある可能性も含む）が存在する場合があっても、Client-Cert ヘッダーフィールドの範囲は意図的に、発端のクライアントが TTRP との接続で提示した証明書をオリジンサーバーに公開することに限定されています。

1.1. 要件表記と規約

本書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、ここに示すとおり全て大文字で現れる場合に限り、BCP 14 の [RFC2119] および [RFC8174] に記載されたとおりに解釈されます。

1.2. 用語と適用範囲

本書では構文と解析を指定するために RFC 8941 のセクション 3 からの用語 List と Byte Sequence を使用します。

"TLS クライアント証明書認証" や "相互認証された TLS" といった表現は、本書全体で、通常の TLS サーバー認証に加えてクライアントが X.509 証明書を提示し（[RFC5280] を参照）、TLS 接続のネゴシエーションまたはその再開時に対応する秘密鍵の所持をサーバーに証明するプロセスを指します。現代の TLS 版（[TLS] や [TLS1.2]）では、相互認証はクライアントがハンドシェイク中に Certificate と CertificateVerify メッセージを送信し、サーバーが CertificateVerify と Finished メッセージを検証することを必要とします。

HTTP/2 は TLS 1.2 の再ネゴシエーションを制限し（RFC 9113 セクション 9.2.1）、TLS 1.3 のポストハンドシェイク認証を禁止します（RFC 9113 セクション 9.2.3）。しかし、これらはサーバーが HTTP/1.1 のリクエストに基づいてクライアント証明書を要求するかどうかを決定するリアクティブなクライアント証明書認証を実装するために使われることがあります。このような接続上でクライアント証明書の受領と検証の後に送信される HTTP アプリケーションデータも相互認証されており、本書で説明するメカニズムに適しています。ポストハンドシェイク認証の場合、実務上稀ではあるものの、接続上でクライアントから複数の証明書や証明書チェーンが提示される可能性があります。この場合、本書で説明するヘッダーフィールドに利用されるのは最後に行われたポストハンドシェイク認証の証明書とチェーンのみです。

2. HTTP ヘッダーフィールドと処理ルール

本書は、相互認証された TLS 接続のクライアント証明書情報を伝達するために、以下に示すヘッダー（それぞれセクション 2.2 と 2.3 でさらに定義されます）を指定します。これらのヘッダーはリバースプロキシからオリジンサーバーへの情報伝達を行います。

Client-Cert:
リバースプロキシとの TLS ハンドシェイクでクライアントが使用したエンドエンティティ証明書。
Client-Cert-Chain:
リバースプロキシとの TLS ハンドシェイクでクライアントが提供したエンドエンティティ証明書の検証に使用された証明書チェーン。

2.1. エンコーディング

本書のヘッダーは、バイトシーケンス（RFC 8941 の セクション 3.3.5）として証明書をエンコードします。ここでのバイナリデータの値は DER エンコードされた [ITU.X690] による X.509 証明書 ([RFC5280]) です。実質的には、バイナリ DER 証明書を base64（改行や空白、base64 アルファベット外の文字を含めない）でエンコードし、両端をコロンで囲むことを意味します。

証明書はしばしば、RFC 7468 の セクション 5.1 に記述されるようなテキスト形式で保存されることがあり、これはバイトシーケンスとほぼ互換性があります。そのような形式で証明書がエンコードされている場合、"---(BEGIN|END) CERTIFICATE---" を ":" に置き換え、改行を削除するだけで適切なアイテムを生成できます。

2.3. Client-Cert-Chain HTTP ヘッダーフィールド

TLS 終端リバースプロキシ導入の文脈では、プロキシは MAY Client-Cert-Chain HTTP ヘッダーフィールドを用いて証明書チェーンをバックエンドアプリケーションに提供できます。

Client-Cert-Chain は RFC 8941 の セクション 3.1 に記される List です。リスト内の各アイテムは セクション 2.1 に記述された通りにエンコードされたバイトシーケンスでなければなりません。順序は TLS の順序（RFC 8446 セクション 4.4.2 に記載）と同じです。

Client-Cert-Chain は Client-Cert が存在する場合にのみ現れることができ、Client-Cert に既に含まれているエンドエンティティ証明書を再び含んではなりません（MUST NOT）。ルート証明書はターゲットのオリジンサーバーが省略された信頼アンカーを所持していることが知られている場合、Client-Cert-Chain から省略してもよい（MAY）です。

Client-Cert-Chain ヘッダーフィールドは HTTP リクエストでのみ使用され、HTTP レスポンスでは使用してはなりません（MUST NOT）。このヘッダーはリクエスト内でリスト値を持つことや複数回出現することが許容されます（MAY）。ヘッダー圧縮の目的でリストを複数のインスタンスに分割することが有利な場合があります。

付録 A の図 3 に Client-Cert-Chain ヘッダーフィールドの例があります。

2.4. 処理ルール

この節では、相互認証された TLS 接続をネゴシエートした TTRP が、その接続のクライアント証明書をバックエンドのオリジンサーバーに伝達するための適用可能な処理ルールを概説します。この手法は設定または導入オプションとして使用されるものであり、以下に記述する処理ルールはそのオプションが有効になっているサーバーに対するものです。

TTRP はクライアントとの相互認証 TLS 接続の使用をネゴシエートし（例えば [TLS] や [TLS1.2] に記述されるもの）、ポリシーと信頼する認証局に従ってクライアント証明書を検証します。基盤となる TLS 接続上の各 HTTP リクエストは以下の修正を加えてオリジンサーバーに転送されます：

  1. クライアント証明書は転送されるリクエストの Client-Cert ヘッダーフィールドに配置されます（セクション 2.2 を参照）。
  2. 設定されている場合、クライアント証明書の検証チェーンはリクエストの Client-Cert-Chain ヘッダーフィールドに配置されます（セクション 2.3 を参照）。
  3. 元の受信リクエストに Client-Cert または Client-Cert-Chain ヘッダーフィールドが存在する場合、それらは転送前に削除または上書きされなければなりません（MUST）。元の受信リクエストに Client-Cert または Client-Cert-Chain ヘッダーフィールドが含まれている場合、そのリクエストは HTTP 400 応答で拒否されることがあります（MAY）。

クライアント証明書認証の使用がネゴシエートされなかった TLS 接続を介して TTRP に送られたリクエストは、バックエンドに転送する前に Client-Cert および Client-Cert-Chain ヘッダーフィールドのいかなる出現も削除してサニタイズしなければなりません（MUST）。

バックエンドのオリジンサーバーは、Client-Cert リクエストヘッダーフィールドを使用して、クライアントから TTRP への接続が相互認証であったかどうかを判定し、相互認証であればクライアントが提示した証明書を特定できます。クライアント証明書（またはその欠如）に基づくアクセス制御判断は、適切なレスポンスコンテンツを選択するか、証明書がその文脈で受け入れられない場合は HTTP 403 応答で伝えることができます。TLS 層でのエラー表示に依存するクライアントは、そのような TLS レイヤでの不許容な証明書に関する信号を受け取れないことに注意してください。

Client-Cert リクエストヘッダーフィールド値を用いてレスポンスを選択する場合（例：レスポンスコンテンツがアクセス制御される場合）、レスポンスは MUST キャッシュ不可能にする（例：Cache-Control: no-store を送る）か、同一の Client-Cert ヘッダーフィールド値を持つ後続リクエストのみで再利用可能とするために "Vary: Client-Cert" を送る必要があります。TTRP が Vary ヘッダーフィールドに Client-Cert または Client-Cert-Chain を含むレスポンスに遭遇した場合（RFC 9110 の セクション 12.5.5 参照）、TTRP は Vary レスポンスヘッダーフィールドの値を "*" に変換してユーザエージェントがレスポンスをキャッシュするのを防止することが SHOULD 推奨されます。

フォワードプロキシやその他の中継は、Client-Cert または Client-Cert-Chain ヘッダーフィールドをリクエストに追加したり、既存の Client-Cert または Client-Cert-Chain ヘッダーフィールドを変更してはなりません（MUST NOT）。同様に、クライアントはリクエストで Client-Cert または Client-Cert-Chain ヘッダーフィールドを使用してはなりません（MUST NOT）。

3. 導入上の考慮事項

3.1. ヘッダーフィールド圧縮

もし TTRP とオリジン間の接続がヘッダーフィールド圧縮（例：HPACK [HPACK] や QPACK [QPACK]）に対応しており、かつ TTRP が複数のクライアントのリクエストをその接続に多重化している場合、Client-Cert および Client-Cert-Chain フィールド値のサイズと変動は圧縮効率を著しく低下させる可能性があります。オリジンは動的テーブルのサイズを増やすことで効率低下を緩和できるかもしれません。TTRP がオリジンの動的テーブルが十分に大きくないと判断した場合、フィールド値を常にリテラルとして送信し、テーブルに入れない方が有益な場合があります。

3.2. メッセージヘッダのサイズ

サーバーが処理可能なより大きなメッセージヘッダを受信した場合、HTTP 431 (Request Header Fields Too Large) ステータスコードを送信できます（RFC 6585 の セクション 5 参照）。証明書データを含むフィールド値の典型的なサイズのため、受信者はより大きな最大ヘッダサイズを許容するように設定する必要があるかもしれません。クライアントに広告可能な最大許容ヘッダサイズを持つ接続（例：HTTP/2 や HTTP/3）上でクライアント証明書ヘッダーフィールドを生成する中継は、送信するリクエストのヘッダの追加サイズを考慮して、クライアントに広告する値を受信するリクエストよりも十分小さくする必要があります。

3.3. TLS セッション再開

一部の TLS 実装はセッション再開時にクライアント証明書情報を保持しないことがあります。再開時に Client-Cert および Client-Cert-Chain の不整合な値を提供するとエラーにつながる可能性があるため、これらの値を提供できない実装は、クライアント証明書付き接続に対しては再開を無効にするか、あるいは再開後に利用できない可能性がある場合は初めに Client-Cert および Client-Cert-Chain フィールドを省略することを SHOULD 推奨します。

4. セキュリティに関する考慮事項

ここで説明するヘッダーフィールドは、TTRP とバックエンドまたはオリジンサーバーが、クライアントの視点からは相互認証された TLS 接続上の単一の論理的なサーバーサイド HTTPS 展開として機能することを可能にします。しかし、想定外の使用ケースでこれらのヘッダーフィールドを使うと、TLS クライアント証明書認証によって提供される保護を損なう可能性があります。したがって、ヘッダーフィールドの送信およびその値に依存する際には、以下に述べるような措置を講じて意図しない利用を防止する必要があります。

Client-Cert および Client-Cert-Chain ヘッダーフィールドの生成と消費は、それぞれ TTRP とバックエンドサーバー（あるいはそのサーバー内の個々のアプリケーション）で設定可能なオプションであるべきです。両者のデフォルト設定はヘッダーフィールドを使用しないこととし、機能を利用するには「オプトイン」が必要であるべきです（SHOULD）。

フィールド注入を防ぐために、バックエンドサーバーは信頼された TTRP（または TTRP からの信頼されたパス上の他のプロキシ）からのみ Client-Cert および Client-Cert-Chain ヘッダーフィールドを受け入れるべきです（MUST）。TTRP は受信リクエストを転送する前に既存のフィールドを削除または上書きしてサニタイズしなければなりません（MUST）。そうしないと、任意のクライアントがバックエンドに対して TTRP からのものであるかのように見えるフィールド値を制御できてしまいます。フィールド注入を防止する他の多くの方法（フィールド名や値に一意の秘密値を含める、署名・HMAC・AEAD を適用する等）が可能ですが、一般的な共通メカニズムは存在しないため、本書で一時的な個別対策を定義するのは不適切です。ジェネリックな共通解が現在存在しないため、フィールドの削除とサニタイズが実務上の事実上の保護手段となっています。適切に実装されたサニタイズは十分であり、これはセキュリティ考慮（セクション 4）の規範的要件です。

TTRP とバックエンドサーバー間の通信は、盗聴や改ざんから保護されている必要があります。

設定オプションとリクエストのサニタイズはそれぞれのサーバーの必要な機能です。他の要件は導入により異なる方法で満たされ得ます。例えば、TTRP とバックエンド間の通信が何らかの方法で認証され、Client-Cert および Client-Cert-Chain ヘッダーフィールドの挿入と消費がその接続上でのみ行われるようにすることが考えられます。付録 B.3 の HTTP Message Signatures の適用例はその一例です。あるいはネットワークトポロジーによりバックエンドアプリケーションが TTRP からのリクエストのみを受け付け、プロキシがそのサーバーにのみリクエストを行えるようなプライベートネットワーク構成が取られることもあります。本書で定めた要件を満たす他の導入もあり得ます。

5. IANA に関する考慮事項

5.1. HTTP フィールド名の登録

IANA は "HTTP Semantics" によって定義された "Hypertext Transfer Protocol (HTTP) Field Name Registry" に以下のエントリを登録しました：

表 1: Hypertext Transfer Protocol (HTTP) Field Name Registry
フィールド名 ステータス 参照
Client-Cert permanent RFC 9440, セクション 2
Client-Cert-Chain permanent RFC 9440, セクション 2

6. 参考文献

6.1. ノルマティブ参考文献

[HTTP]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, 2022年6月, <https://www.rfc-editor.org/info/rfc9110>。
[ITU.X690]
ITU-T, “Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)”, ITU-T Recommendation X.690, 2021年2月, <https://www.itu.int/rec/T-REC-X.690/en>。
[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, 1997年3月, <https://www.rfc-editor.org/info/rfc2119>。
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, RFC 5280, 2008年5月, <https://www.rfc-editor.org/info/rfc5280>。
[RFC8174]
Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, 2017年5月, <https://www.rfc-editor.org/info/rfc8174>。
[STRUCTURED-FIELDS]
Nottingham, M. and P-H. Kamp, “Structured Field Values for HTTP”, RFC 8941, 2021年2月, <https://www.rfc-editor.org/info/rfc8941>。

6.2. インフォマティブ参考文献

[HPACK]
Peon, R. and H. Ruellan, “HPACK: Header Compression for HTTP/2”, RFC 7541, 2015年5月, <https://www.rfc-editor.org/info/rfc7541>。
[HTTP/1.1]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1”, RFC 9112, 2022年6月, <https://www.rfc-editor.org/info/rfc9112>。
[HTTP/2]
Thomson, M., Ed. and C. Benfield, Ed., “HTTP/2”, RFC 9113, 2022年6月, <https://www.rfc-editor.org/info/rfc9113>。
[HTTP/3]
Bishop, M., Ed., “HTTP/3”, RFC 9114, 2022年6月, <https://www.rfc-editor.org/info/rfc9114>。
[HTTPSIG]
Backman, A., Ed., Richer, J., Ed., and M. Sporny, “HTTP Message Signatures”, draft-ietf-httpbis-message-signatures-17, 2023年5月（作業中）、<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-17>。
[QPACK]
Krasic, C., Bishop, M., and A. Frindell, Ed., “QPACK: Field Compression for HTTP/3”, RFC 9204, 2022年6月, <https://www.rfc-editor.org/info/rfc9204>。
[RFC6585]
Nottingham, M. and R. Fielding, “Additional HTTP Status Codes”, RFC 6585, 2012年4月, <https://www.rfc-editor.org/info/rfc6585>。
[RFC7239]
Petersson, A. and M. Nilsson, “Forwarded HTTP Extension”, RFC 7239, 2014年6月, <https://www.rfc-editor.org/info/rfc7239>。
[RFC7468]
Josefsson, S. and S. Leonard, “Textual Encodings of PKIX, PKCS, and CMS Structures”, RFC 7468, 2015年4月, <https://www.rfc-editor.org/info/rfc7468>。
[RFC8705]
Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”, RFC 8705, 2020年2月, <https://www.rfc-editor.org/info/rfc8705>。
[TLS1.2]
Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, 2008年8月, <https://www.rfc-editor.org/info/rfc5246>。
[TLS]
Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, 2018年8月, <https://www.rfc-editor.org/info/rfc8446>。

付録 A. 例

仮の例として、TLS クライアントが相互認証された TLS 接続を TTRP と確立する際に 図 1 からクライアント証明書と中間証明書を提示する場合、プロキシはバックエンドに図 2 に示す Client-Cert フィールドを送信します。図 2 と図 3 のフィールド値には表示と整形の便宜のために改行や余分な空白が追加されている点に注意してください。

-----BEGIN CERTIFICATE-----
MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJMZXQncyBB
dXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0yMDAx
MTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p
5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIw
ADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMC
BsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1w
bGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMje
SkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQswCQYDVQQGEwJVUzEbMBkG
A1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQDDCFMZXQncyBBdXRoZW50
aWNhdGUgUm9vdCBBdXRob3JpdHkwHhcNMjAwMTE0MjEzMjMwWhcNMzAwMTExMjEz
MjMwWjA6MRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxB
IEludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJf+aA54
RC5pyLAR5yfXVYmNpgd+CGUTDp2KOGhc0gK91zxhHesEYkdXkpS2UN8Kati+yHtW
CV3kkhCngGyv7RqjZjBkMB0GA1UdDgQWBBRm3WjLa38lbEYCuiCPct0ZaSED2DAf
BgNVHSMEGDAWgBTEA2Q6eecKu9g9yb5glbkhhVINGDASBgNVHRMBAf8ECDAGAQH/
AgEAMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDAgNJADBGAiEA5pLvaFwRRkxo
mIAtDIwg9D7gC1xzxBl4r28EzmSO1pcCIQCJUShpSXO9HDIQMUgH69fNDEMHXD3R
RX5gP7kuu2KGMg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICBjCCAaygAwIBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAYT
AlVTMRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdGUxKjAoBgNVBAMMIUxldCdz
IEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvcml0eTAeFw0yMDAxMTQyMTI1NDVaFw00
MDAxMDkyMTI1NDVaMFYxCzAJBgNVBAYTAlVTMRswGQYDVQQKDBJMZXQncyBBdXRo
ZW50aWNhdGUxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvc
ml0eTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFoaHU+Z5bPKmGzlYXtCf+E6
HYj62fORaHDOrt+yyh3H/rTcs7ynFfGn+gyFsrSP3Ez88rajv+U2NfD0o0uZ4Pmj
YzBhMB0GA1UdDgQWBBTEA2Q6eecKu9g9yb5glbkhhVINGDAfBgNVHSMEGDAWgBTE
A2Q6eecKu9g9yb5glbkhhVINGDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQE
AwIBhjAKBggqhkjOPQQDAgNIADBFAiEAmAeg1ycKHriqHnaD4M/UDBpQRpkmdcRF
YGMg1Qyrkx4CIB4ivz3wQcQkGhcsUZ1SOImd/lq1Q0FLf09rGfLQPWDc
-----END CERTIFICATE-----

図 1: 証明書チェーン（クライアント証明書が先）

Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJ
 MZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0
 yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFkwEwYHKoZ
 Izj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmckC8vdgJ1p5Be
 5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDVR0TBAIwADAfBgN
 VHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf8EBAMCBsAwEwYDVR0
 lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV4YW1wbGUuY29tMAoGCCq
 GSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6bMjeSkC3dFCOOB8TAiEAx/k
 HSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:

図 2: オリジンサーバーへの HTTP リクエスト内のヘッダーフィールド

プロキシが証明書チェーンも含めるよう構成されている場合、Client-Cert-Chain ヘッダーフィールドも含めます。以下の例は TTRP がルート証明書を挿入する例を示しますが、多くの導入では信頼アンカーを省略する選択をすることに注意してください。

Client-Cert-Chain: :MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQsw
 CQYDVQQGEwJVUzEbMBkGA1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQ
 DDCFMZXQncyBBdXRoZW50aWNhdGUgUm9vdCBBdXRob3JpdHkwHhcNMjAwMTE0Mj
 EzMjMwWhcNMzAwMTExMjEzMjMwWjA6MRswGQYDVQQKDBJMZXQncyBBdXRoZW50a
 WNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTBZMBMGByqGSM49AgEG
 CCqGSM49AwEHA0IABJf+aA54RC5pyLAR5yfXVYmNpgd+CGUTDp2KOGhc0gK91zx
 hHesEYkdXkpS2UN8Kati+yHtWCV3kkhCngGyv7RqjZjBkMB0GA1UdDgQWBBRm3W
 jLa38lbEYCuiCPct0ZaSED2DAfBgNVHSMEGDAWgBTEA2Q6eecKu9g9yb5glbkhh
 VINGDASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjO
 PQQDAgNJADBGAiEA5pLvaFwRRkxomIAtDIwg9D7gC1xzxBl4r28EzmSO1pcCIQC
 JUShpSXO9HDIQMUgH69fNDEMHXD3RRX5gP7kuu2KGMg==:, :MIICBjCCAaygAw
 IBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAYTAlVTMRswGQYDV
 QQKDBJMZXQncyBBdXRoZW50aWNhdGUxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRp
 Y2F0ZSBSb290IEF1dGhvcml0eTAeFw0yMDAxMTQyMTI1NDVaFw00MDAxMDkyMTI
 1NDVaMFYxCzAJBgNVBAYTAlVTMRswGQYDVQQKDBJMZXQncyBBdXRoZW50aWNhdG
 UxKjAoBgNVBAMMIUxldCdzIEF1dGhlbnRpY2F0ZSBSb290IEF1dGhvcml0eTBZM
 BMGByqGSM49AgEGCCqGSM49AwEHA0IABFoaHU+Z5bPKmGzlYXtCf+E6HYj62fOR
 aHDOrt+yyh3H/rTcs7ynFfGn+gyFsrSP3Ez88rajv+U2NfD0o0uZ4PmjYzBhMB0
 GA1UdDgQWBBTEA2Q6eecKu9g9yb5glbkhhVINGDAfBgNVHSMEGDAWgBTEA2Q6ee
 cKu9g9yb5glbkhhVINGDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBh
 jAKBggqhkjOPQQDAgNIADBFAiEAmAeg1ycKHriqHnaD4M/UDBpQRpkmdcRFYGMg
 1Qyrkx4CIB4ivz3wQcQkGhcsUZ1SOImd/lq1Q0FLf09rGfLQPWDc:

図 3: オリジンサーバーへの HTTP リクエスト内の証明書チェーン

付録 B. 選択された設計上の考慮事項

B.1. フィールド注入

本書は、TTRP が受信リクエストのフィールドをサニタイズし、Client-Cert および Client-Cert-Chain ヘッダーフィールドの既存のインスタンスを削除または上書きしてからそのリクエストをバックエンドアプリケーションに転送することを要求します。そうしないと、クライアントが自身で値を注入し、それがバックエンドからは TTRP 由来であるかのように見えてしまいます。フィールド注入の検出と防止には、一意の秘密値をフィールド名や値の一部として使用することや署名、HMAC、AEAD の適用など多数の方法が考えられますが、共通の一般的なメカニズムは存在しません。クライアントによるフィールド注入の問題は本書の機能に特有のものではないため、本書で一時的な個別の解決策を定義することは不適切です。一般的な共通解が現在存在しないため、フィールドの削除とサニタイズが実務上の事実上の防護手段となっています。フィールドのサニタイズは適切に実装されれば十分であり、これは セクション 4 の規範的要件です。

B.2. Forwarded HTTP 拡張

RFC 7239 で定義された Forwarded HTTP ヘッダーフィールドは、プロキシ処理で失われた情報を開示することをプロキシコンポーネントに許します。本書で問題とする TLS クライアント証明書情報は Forwarded フィールドの拡張パラメータとして伝達できたかもしれませんが、その場合避けたいいくつかの不利点がありました。Forwarded フィールドの構文はプロキシされる HTTP リクエストのフルチェーンに関する情報を許容しますが、本書の Client-Cert および Client-Cert-Chain ヘッダーは、発端のクライアントが TTRP と確立した TLS 接続で提示した証明書に関する情報だけをバックエンドアプリケーションに伝えることに関心があります。Forwarded のマルチホップ構文は表現力がありますが処理が複雑であり、より重要な点として、フィールド注入を防止するためにセクション 4 で要求されるようにその内容を適切にサニタイズすることがはるかに困難でエラーを生みやすくなります。したがって、本書はより平坦で簡潔な構造を選択しました。

B.3. 証明書本体と証明書チェーン

アプリケーションによって、クライアント証明書から必要とする情報は様々です。例えばサブジェクトや発行者の識別名、サブジェクト代替名、シリアル番号、サブジェクト公開鍵情報、フィンガープリントなどが挙げられます。さらに、RFC 8705 に記載されたような一部のアプリケーションは証明書全体を利用します。そのような要件を収容し、特定の証明書情報を選り好みしないことで広い適用性を確保するため、本書は Client-Cert フィールドの値としてフルにエンコードされた証明書を渡すことを選択しました。

相互認証された TLS 接続のクライアント証明書とチェーンの検証は通常ハンドシェイク中に TTRP によって行われます。証明書検証の責任が TTRP にあるため、エンドエンティティ証明書だけでオリジンサーバーのニーズに十分であることが多いです。追加情報が必要なオリジンサーバー導入の場合は、別個の Client-Cert-Chain フィールドで証明書チェーンを伝達できます。

謝辞

著者は、本書に様々な形で貢献してくれた以下の個人に感謝します。貢献は、文書作成の一般的な支援から具体的なフィードバックや内容提供まで多岐にわたります：

  • Evan Anderson

  • Annabelle Backman

  • Alan Frindell

  • Rory Hewitt

  • Fredrik Jeansson

  • Benjamin Kaduk

  • Torsten Lodderstedt

  • Kathleen Moriarty

  • Mark Nottingham

  • Erik Nygren

  • Mike Ounsworth

  • Lucas Pardue

  • Matt Peterson

  • Eric Rescorla

  • Justin Richer

  • Michael Richardson

  • Joe Salowey

  • Rich Salz

  • Mohit Sethi

  • Rifaat Shekh-Yusef

  • Travis Spencer

  • Nick Sullivan

  • Willy Tarreau

  • Martin Thomson

  • Peter Wu

  • Hans Zandbelt

著者の連絡先

Brian Campbell
Ping Identity
EMail: bcampbell@pingidentity.com
Mike Bishop (editor)
Akamai
EMail: mbishop@evequefou.be