인터넷 엔지니어링 태스크 포스 (IETF) B. Campbell
요청 의견(Request for Comments): 9440 Ping Identity
분류: 정보 M. Bishop, 편집자
ISSN: 2070-1721 Akamai
2023년 7월

클라이언트 인증서 HTTP 헤더 필드

초록

이 문서는 TLS 종료 리버스 프록시(TTRP)가 상호 인증된 TLS 연결의 클라이언트 인증서 정보를 공통적이고 예측 가능한 방식으로 오리진 서버에 전달할 수 있도록 하는 HTTP 확장 헤더 필드를 설명합니다.

이 메모의 상태

이 문서는 인터넷 표준 트랙 명세가 아니며, 정보 제공 목적으로 게시되었습니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물입니다. 이는 IETF 커뮤니티의 합의를 반영합니다. 이 문서는 공개 검토를 거쳤고 인터넷 엔지니어링 운영 그룹(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-티어 아키텍처, 콘텐츠 전송 네트워크(CDN), 애플리케이션 로드 밸런싱 서비스, 인그레스 컨트롤러 등 다양한 형태로 존재합니다.

그리 널리 보편적이지는 않지만 TLS 클라이언트 인증서 인증이 때때로 사용되며, 그러한 경우 오리진 서버는 애플리케이션 로직을 위해 클라이언트 인증서에 대한 정보를 요구하는 경우가 많습니다. 이러한 로직에는 접근 제어 결정, 감사 로깅, 발급된 토큰이나 쿠키를 인증서에 바인딩(및 해당 바인딩의 검증 포함)하는 것 등이 포함될 수 있습니다. 인증서에서 필요한 구체적 세부 사항은 애플리케이션 요구사항에 따라 달라집니다. 이와 같은 애플리케이션 배포가 실무에서 작동하려면, 리버스 프록시는 클라이언트 인증서에 관한 정보를 오리진 애플리케이션 서버로 전달해야 합니다. 작성 시점에서 이 정보는 종종 비표준 필드를 사용하여(어떤 인코딩으로) 또는 인증서의 개별 부분을 HTTP 요청에 포함시켜 오리진 서버로 전달되는 방식으로 전송됩니다. 이 해결책은 작동하지만, 사용되는 필드 이름이나 노출되는 인증서 부분, 인증서 인코딩 방식 등의 구현 선택에 따라 독립적으로 개발된 구성 요소 간 상호운용성이 까다롭거나 불가능할 수 있습니다. 이러한 일반적인 기능에 대해 잘 알려진 예측 가능한 접근 방식이 있다면 독립 구현체 간의 상호운용성을 개선하고 단순화할 수 있습니다.

이 문서의 범위는 기존 관행을 기술하면서 상호운용성 향상과 낮은 운영 부담을 촉진하기에 충분한 구체적 세부사항을 규정하는 것입니다. 따라서 이 문서는 TLS 종료 리버스 프록시(TTRP)가 백엔드 오리진 서버로 전송하는 요청에 추가하는 두 개의 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. 용어 및 적용범위

이 문서는 구문 및 구문 분석을 지정하기 위해 Section 3의 [STRUCTURED-FIELDS]에서 사용되는 다음 용어를 사용합니다: List 및 Byte Sequence.

"TLS 클라이언트 인증서 인증" 또는 "상호 인증된 TLS"와 같은 문구는 이 문서 전체에서, TLS 서버 인증(서버 인증서 사용)에 더해 클라이언트가 X.509 인증서([RFC5280])을 서버에 제시하고 해당 개인 키의 소유를 증명하여 TLS 연결 또는 해당 연결의 재개를 협상하는 과정을 가리킵니다. 현대 TLS 버전([TLS] 및 [TLS1.2])에서는 상호 인증이 핸드셰이크 동안 클라이언트가 Certificate 및 CertificateVerify 메시지를 보내고 서버가 CertificateVerify 및 Finished 메시지를 검증해야 함을 요구합니다.

HTTP/2는 TLS 1.2 재협상을 제한하고(Section 9.2.1 of [HTTP/2]) TLS 1.3의 포스트-핸드셰이크 인증을 금지합니다(Section 9.2.3 of [HTTP/2]). 그러나 이들은 때때로 HTTP/1.1([HTTP/1.1])에서 반응형 클라이언트 인증 구현을 위해 사용되며, 이 경우 서버는 HTTP 요청을 기반으로 클라이언트 인증서 요청 여부를 결정합니다. 그런 연결에서 클라이언트 인증서를 수신하고 검증한 후 전송되는 HTTP 애플리케이션 데이터는 상호 인증된 것으로 간주되며 본 문서에서 설명한 메커니즘에 적합합니다. 포스트-핸드셰이크 인증의 경우, 실제로는 드물지만 연결에서 클라이언트로부터 여러 인증서 및 인증서 체인이 올 수 있는 가능성도 있습니다. 이 경우에는 마지막 포스트-핸드셰이크 인증의 인증서와 체인만이 이 문서에서 설명하는 헤더 필드에 사용되어야 합니다.

2. HTTP 헤더 필드 및 처리 규칙

이 문서는 상호 인증된 TLS 연결의 클라이언트 인증서 정보를 전달하기 위해 섹션 2.2 및 2.3에서 자세히 정의된 다음 헤더를 지정합니다. 이들 헤더는 리버스 프록시에서 오리진 서버로 정보를 전달합니다.

Client-Cert:
리버스 프록시와의 TLS 핸드셰이크에서 클라이언트가 사용한 엔드 엔티티 인증서.
Client-Cert-Chain:
리버스 프록시와의 TLS 핸드셰이크에서 클라이언트가 제공한 엔드 엔티티 인증서의 검증에 사용된 인증서 체인.

2.1. 인코딩

이 문서에 나오는 헤더는 인증서를 Byte Sequence(Section 3.3.5 of [STRUCTURED-FIELDS])로 인코딩합니다. 이진 데이터의 값은 DER로 인코딩된 [ITU.X690] 형식의 X.509 인증서([RFC5280])입니다. 실질적으로 이는 바이너리 DER 인증서를 base64로 인코딩하고(줄 바꿈, 공백 또는 base64 알파벳 외의 문자는 없이) 양쪽에 콜론으로 구분하는 것을 의미합니다.

인증서는 종종 Section 5.1 of [RFC7468]에서 설명된 것과 같은 인코딩된 텍스트 형식으로 저장되며, 이는 Byte Sequence와 거의 호환됩니다. 만약 인증서가 그러한 형식으로 인코딩되어 있다면, "---(BEGIN|END) CERTIFICATE---"를 ":"로 바꾸고 줄 바꿈을 제거하는 것으로 적절한 항목을 생성할 수 있습니다.

2.3. Client-Cert-Chain HTTP 헤더 필드

TLS 종료 리버스 프록시 배포의 맥락에서, 프록시는 Client-Cert-Chain HTTP 헤더 필드를 통해 인증서 체인을 백엔드 애플리케이션에 제공할 수 있습니다(MAY).

Client-Cert-Chain는 List(Section 3.1 of [STRUCTURED-FIELDS])입니다. List의 각 항목은 섹션 2.1에서 설명된 방식으로 인코딩된 Byte Sequence여야 합니다. 순서는 TLS에서의 순서와 동일합니다(예: Section 4.4.2 of [TLS] 참조).

Client-Cert-Chain은 Client-Cert가 있는 경우에만 나타날 수 있으며(Client-Cert가 존재하지 않으면 나타나서는 안 됨), Client-Cert에 이미 포함된 엔드 엔티티 인증서를 중복으로 포함해서는 안 됩니다. 루트 인증서는 대상 오리진 서버가 누락된 신뢰 앵커를 보유하고 있는 것으로 알려져 있는 경우에 한해 Client-Cert-Chain에서 생략될 수 있습니다.

Client-Cert-Chain 헤더 필드는 HTTP 요청에서만 사용되어야 하며 HTTP 응답에서는 MUST NOT 사용되어서는 안 됩니다. 이 필드는 요청에서 값의 목록을 가질 수 있으며, 여러 번 발생할 수도 있습니다. 헤더 압축을 위해서는 목록을 여러 개의 인스턴스로 분할하는 것이 유리할 수 있습니다.

Figure 3는 Appendix A의 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 응답으로 거부될 수 있습니다.

클라이언트 인증서 인증 사용이 협상되지 않은 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이 포함된 응답을 만난다면(Section 12.5.5 of [HTTP]), 응답의 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. 메시지 헤더 크기

수신된 메시지 헤더가 서버가 처리할 준비가 된 크기보다 큰 경우, 수신 서버는 Section 5 of [RFC6585]에 따라 HTTP 431(요청 헤더 필드가 너무 큼) 상태 코드를 보낼 수 있습니다. 인증서 데이터를 포함하는 필드 값의 전형적 크기로 인해, 수신자는 더 큰 최대 헤더 크기를 허용하도록 구성해야 할 수 있습니다. 클라이언트에게 허용되는 최대 헤더 크기를 광고할 수 있는 연결(예: HTTP/2 [HTTP/2] 또는 HTTP/3 [HTTP/3])에서 클라이언트 인증서 헤더 필드를 생성하는 중간자는, 자신이 수신하는 요청과 비교하여 자신이 전송하는 요청의 헤더가 더 커질 것을 감안하여 클라이언트에 광고하는 값을 충분히 작게 설정해야 합니다.

3.3. TLS 세션 재개

일부 TLS 구현은 재개 시 클라이언트 인증서 정보를 보관하지 않습니다. 재개 시에 Client-Cert 및 Client-Cert-Chain의 불일치 값이 제공되면 오류가 발생할 수 있으므로, 이러한 값을 제공할 수 없는 구현체는 클라이언트 인증서가 있는 연결에 대해 재개를 비활성화하거나 재개 후에 사용할 수 없을 가능성이 있는 경우 처음에는 Client-Cert 또는 Client-Cert-Chain 필드를 생략하는 것이 SHOULD 권장됩니다.

4. 보안 고려사항

여기에 설명된 헤더 필드는 TTRP와 백엔드 또는 오리진 서버가 클라이언트 관점에서 단일 논리적 서버 측 HTTPS 배포로 동작하도록 허용합니다. 그러나 의도된 사용 사례 밖에서 헤더 필드를 사용하는 것은 TLS 클라이언트 인증서 인증이 제공하는 보호를 약화시킬 수 있습니다. 따라서 헤더 필드를 보내거나 그 값을 신뢰할 때 의도하지 않은 사용을 방지하기 위해 아래에 설명된 단계와 같은 조치를 취해야 합니다.

Client-Cert 및 Client-Cert-Chain 헤더 필드를 생성하고 소비하는 기능은 각각 TTRP 및 백엔드 서버(또는 해당 서버의 개별 애플리케이션)에서 구성 가능한 옵션으로 제공되어야 합니다(SHOULD). 둘 다 기본 구성은 헤더 필드를 사용하지 않도록 하여 기능을 "옵트인" 방식으로 요구해야 합니다.

필드 주입을 방지하기 위해 백엔드 서버는 신뢰된 TTRP(또는 TTRP로부터의 신뢰 경로에 있는 다른 프록시)로부터만 Client-Cert 및 Client-Cert-Chain 헤더 필드를 수락해야 합니다(MUST). TTRP는 전달하기 전에 들어온 요청을 정리하여 기존 필드 인스턴스를 제거하거나 덮어써야 합니다(MUST). 그렇지 않으면 임의의 클라이언트가 백엔드에서 사용되는 필드 값을 제어할 수 있습니다. 필드 주입을 감지하고 방지하는 다른 여러 방법(필드 이름 또는 값의 일부로 고유한 비밀값을 사용하는 것, 서명/ HMAC/AEAD 적용 등)이 존재하지만 공통의 일반적 메커니즘은 없습니다. 클라이언트 필드 주입 문제는 이 문서의 기능에 국한된 것이 아니므로 본 문서에서 일회성 솔루션을 정의하는 것은 적절하지 않습니다. 일반적인 공통 솔루션이 현재 존재하지 않기 때문에, 필드를 제거하고 정리하는 방식이 실무에서 사실상 필드 주입으로부터 보호하는 수단이며, 적절히 구현된 경우 정리는 섹션 4의 규범적 요구사항을 충족합니다.

TTRP와 백엔드 서버 간의 통신은 도청 및 변조로부터 보호되어야 합니다.

구성 옵션과 요청 정리는 각각의 서버에서 필요한 기능입니다. 나머지 요구사항들은 특정 배포에 따라 여러 방식으로 충족될 수 있습니다. 예를 들어 TTRP와 백엔드 또는 오리진 서버 간의 통신은 어떤 방식으로 인증될 수 있으며, Client-Cert 및 Client-Cert-Chain 헤더 필드의 삽입 및 소비는 해당 연결에서만 발생하도록 할 수 있습니다. [HTTPSIG]의 부록 B.3은 HTTP 메시지 서명을 적용한 한 예를 제공합니다. 또는 네트워크 토폴로지가 프록시가 오직 해당 서버로만 요청을 보낼 수 있고 백엔드 애플리케이션이 오직 TTRP로부터의 요청만 수락할 수 있는 사설 네트워크를 요구할 수도 있습니다. 본 문서의 요구사항을 충족하는 다른 배포도 가능합니다.

5. IANA 고려사항

5.1. HTTP 필드 이름 등록

IANA는 "HTTP Semantics"([HTTP])에 의해 정의된 "Hypertext Transfer Protocol (HTTP) Field Name Registry"에 다음 항목을 등록했습니다:

Table 1: Hypertext Transfer Protocol (HTTP) Field Name Registry
Field Name Status Reference
Client-Cert permanent RFC 9440, Section 2
Client-Cert-Chain permanent RFC 9440, Section 2

6. 참고 문헌

6.2. 정보 참조

[HPACK]
Peon, R. 및 H. Ruellan, “HPACK: Header Compression for HTTP/2”, RFC 7541, DOI 10.17487/RFC7541, 2015년 5월, <https://www.rfc-editor.org/info/rfc7541>.
[HTTP/1.1]
Fielding, R., 편집자, Nottingham, M., 편집자, 및 J. Reschke, 편집자, “HTTP/1.1”, STD 99, RFC 9112, DOI 10.17487/RFC9112, 2022년 6월, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/2]
Thomson, M., 편집자 및 C. Benfield, 편집자, “HTTP/2”, RFC 9113, DOI 10.17487/RFC9113, 2022년 6월, <https://www.rfc-editor.org/info/rfc9113>.
[HTTP/3]
Bishop, M., 편집자, “HTTP/3”, RFC 9114, DOI 10.17487/RFC9114, 2022년 6월, <https://www.rfc-editor.org/info/rfc9114>.
[HTTPSIG]
Backman, A., 편집자, Richer, J., 편집자, 및 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., 및 A. Frindell, 편집자, “QPACK: Field Compression for HTTP/3”, RFC 9204, DOI 10.17487/RFC9204, 2022년 6월, <https://www.rfc-editor.org/info/rfc9204>.
[RFC6585]
Nottingham, M. 및 R. Fielding, “Additional HTTP Status Codes”, RFC 6585, DOI 10.17487/RFC6585, 2012년 4월, <https://www.rfc-editor.org/info/rfc6585>.
[RFC7239]
Petersson, A. 및 M. Nilsson, “Forwarded HTTP Extension”, RFC 7239, DOI 10.17487/RFC7239, 2014년 6월, <https://www.rfc-editor.org/info/rfc7239>.
[RFC7468]
Josefsson, S. 및 S. Leonard, “Textual Encodings of PKIX, PKCS, and CMS Structures”, RFC 7468, DOI 10.17487/RFC7468, 2015년 4월, <https://www.rfc-editor.org/info/rfc7468>.
[RFC8705]
Campbell, B., Bradley, J., Sakimura, N., 및 T. Lodderstedt, “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”, RFC 8705, DOI 10.17487/RFC8705, 2020년 2월, <https://www.rfc-editor.org/info/rfc8705>.
[TLS1.2]
Dierks, T. 및 E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, 2008년 8월, <https://www.rfc-editor.org/info/rfc5246>.
[TLS]
Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, 2018년 8월, <https://www.rfc-editor.org/info/rfc8446>.

Appendix A. 예시

가상의 예시에서 TLS 클라이언트가 상호 인증된 TLS 연결을 설정할 때 Figure 1에 있는 클라이언트 및 중간 인증서를 제시한다고 가정하면, 프록시는 백엔드에 전송되는 요청에 Figure 2에 표시된 Client-Cert 필드를 보낼 것입니다. Figure 2와 Figure 3의 필드 값에는 표시 및 포맷 목적상 줄 바꿈과 여분의 공백이 추가되어 있음을 유의하십시오.

-----BEGIN CERTIFICATE-----
MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJMZXQncyBB
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQswCQYDVQQGEwJVUzEbMBkG
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICBjCCAaygAwIBAgIJAKS0yiqKtlhoMAoGCCqGSM49BAMCMFYxCzAJBgNVBAYT
...
-----END CERTIFICATE-----

Figure 1: Certificate Chain (with Client Certificate First)

Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKDBJ
 MZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQTAeFw0
...
=:

Figure 2: Header Field in HTTP Request to Origin Server

프록시가 인증서 체인도 포함하도록 구성된 경우, Client-Cert-Chain 헤더 필드도 포함될 것입니다. 다음 예시는 TTRP가 루트 인증서를 삽입하는 모습을 보여주지만, 많은 배포는 신뢰 앵커를 생략하는 것을 선택할 것임을 유의하십시오.

Client-Cert-Chain: :MIIB5jCCAYugAwIBAgIBFjAKBggqhkjOPQQDAjBWMQsw
 CQYDVQQGEwJVUzEbMBkGA1UECgwSTGV0J3MgQXV0aGVudGljYXRlMSowKAYDVQQ
 ...
GfLQPWDc:

Figure 3: Certificate Chain in HTTP Request to Origin Server

Appendix B. 선택적 설계 고려사항

B.1. 필드 주입

이 문서는 TTRP가 들어온 요청을 전달하기 전에 Client-Cert 및 Client-Cert-Chain 헤더 필드의 기존 인스턴스를 제거하거나 덮어써서 필드를 정리할 것을 요구합니다. 그렇지 않으면 클라이언트가 백엔드에 전달되는 값에 대해 자신이 설정한 값을 주입할 수 있습니다. 필드 주입을 감지하고 방지하는 다른 여러 방법(예: 필드 이름 또는 값의 일부로 고유한 비밀값을 사용하거나 서명, HMAC, AEAD 적용 등)이 가능하지만 공통의 일반 메커니즘은 없습니다. 클라이언트 필드 주입 문제는 이 문서의 기능에만 국한된 것이 아니므로 본 문서에서 일회성 솔루션을 정의하는 것은 부적절합니다. 현재 범용적인 공통 솔루션이 존재하지 않으므로, 필드를 제거하고 정리하는 것이 실무에서 필드 주입으로부터 보호하는 사실상의 수단이며, 적절히 구현된 경우 이는 섹션 4의 규범적 요구사항을 충족합니다.

B.2. Forwarded HTTP 확장

[RFC7239]에서 정의된 Forwarded HTTP 헤더 필드는 프록시 과정에서 손실되는 정보를 공개할 수 있도록 허용합니다. 본 문서에서 다루는 TLS 클라이언트 인증서 정보는 Forwarded 필드의 확장 매개변수로 전달될 수도 있었지만, 그렇게 하면 본 문서가 피하고자 한 몇 가지 단점이 있었습니다. Forwarded 필드 구문은 프록시된 HTTP 요청의 전체 체인에 대한 정보를 허용하는 반면, 본 문서의 Client-Cert 및 Client-Cert-Chain 헤더는 오리진 애플리케이션에 전달되어야 하는 원래 클라이언트가 TTRP에 제시한 인증서 정보만을 전달하는 데 관심이 있습니다(클라이언트 관점에서 해당 TTRP는 서버로 보입니다). Forwarded 필드의 다중 홉 구문은 표현력이 높지만 더 복잡하여 처리와 특히 섹션 4에서 요구하는 대로 내용을 적절히 정리하는 것을 더 어렵고 오류가 발생하기 쉬운 작업으로 만들었습니다. 따라서 본 문서는 더 평탄하고 직관적인 구조를 선택했습니다.

B.3. 전체 인증서 및 인증서 체인

애플리케이션마다 클라이언트 인증서에서 필요한 정보(예: subject 및/또는 issuer distinguished name, subject alternative name(s), 일련 번호, subject public key info, 지문 등)가 다릅니다. 또한 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