HTTP 대체 서비스

이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 및 "OPTIONAL"이라는 핵심 단어들은 RFC2119에 설명된 대로 해석됩니다.

클라이언트는 대체 서비스가 오리진 전체를 관할하고 그에 대해 유효하다는 합리적인 확신을 가져야 합니다. 이는 섹션 9.2에서 설명된 공격을 완화합니다.

이 문서의 목적상 "합리적인 확신"은 TLS 기반 프로토콜을 사용하고 [RFC2818]에 정의된 인증서 검사를 수행함으로써 확보될 수 있습니다. 클라이언트는 추가 기준을 요구할 수 있습니다.

예를 들어, 오리진 호스트가 "www.example.com"이고 대체가 "other.example.com"에서 "h2" 프로토콜로 제공되며 제공된 인증서가 "www.example.com"에 대해 유효하다면, 클라이언트는 그 대체를 사용할 수 있습니다. 그러나 둘 중 하나가 "h2c"로 제공되는 경우, 해당 프로토콜에는 (이 명세 출판 시점에) 오리진과 대체 간의 관계를 확립하는 메커니즘이 없으므로 클라이언트는 이를 사용할 수 없습니다.

대체 서비스를 발견하기 위한 메커니즘은 대체 서비스와 연관된 신선도 수명도 연결합니다; 예를 들어 Alt-Svc 헤더 필드는 "ma" 매개변수를 사용합니다.

클라이언트는 대체 서비스가 신선하다고 판단되는 동안 언제든지 오리진 대신 해당 대체 서비스를 사용할 수 있습니다; 구체적인 권장사항은 섹션 2.4를 참조하십시오.

이미 대체 서비스에 대한 연결이 있는 클라이언트는 그 신선도 수명이 끝났다고 해서 사용을 중단할 필요가 없습니다; 캐싱 메커니즘은 새로운 연결을 설정하는 데 대체 서비스를 얼마나 오래 사용할 수 있는지를 제한하기 위한 것이며, 기존 연결의 사용을 제한하기 위한 것은 아닙니다.

대체 서비스는 해당 오리진에 대해 완전한 권한을 가지며, 캐시된 대체 서비스 항목을 제거하거나 갱신하고, 신선도 수명을 연장하며, 오리진 서버가 가질 수 있는 기타 모든 권한을 행사할 수 있습니다.

대체 서비스를 사용하여 클라이언트를 최적의 서버로 보낼 때 네트워크 구성의 변화로 인해 캐시된 값이 최적이 아닌 경우가 발생할 수 있습니다. 따라서 클라이언트는 네트워크 상태에 대한 정보가 있을 때 "persist" 플래그가 값 "1"이 아닌 모든 대체 서비스를 캐시에서 제거하는 것이 권장됩니다.

클라이언트는 TLS 기반의 대체 서비스를 사용하려면 TLS Server Name Indication (SNI)을 지원해야 합니다. 이는 대체 서비스 호스트에서 IP 주소를 절약하는 데 도움이 됩니다.

TLS에서 클라이언트가 제공하는 SNI 정보는 대체가 아닌 오리진의 정보가 됩니다(Host HTTP 헤더 필드 값도 마찬가지입니다).

대체 서비스는 본질적으로 OPTIONAL입니다: 클라이언트는 이를 사용할 의무가 없습니다. 그러나 서버가 대체 서비스를 제공할 때 클라이언트가 예측 가능한 방식으로 동작하는 것이 로드 밸런싱과 같은 목적에 유리합니다.

따라서 이 명세를 지원하는 클라이언트가 대체 서비스를 알게 되면, 해당 대체 서비스 정보가 신선하고(섹션 2.2) 대체 서비스 프로토콜의 보안 속성이 기존 연결보다 바람직한 경우, 클라이언트는 가능한 한 빨리 연관된 오리진에 대한 모든 요청에 그 대체 서비스를 사용해야 합니다. 이용 가능한 대체 서비스는 오리진과 동일한 방식으로 취급되며, 이는 대체 서비스를 광고할 수 있는 능력도 포함합니다.

클라이언트가 여러 대체 서비스를 인지하게 되면, 보안 속성을 염두에 두고 자체 기준에 따라 가장 적합한 것을 선택합니다. 예를 들어 오리진이 여러 버전의 HTTP 지원을 알리기 위해 여러 대체 서비스를 광고할 수 있습니다.

특정 요청에 대해 프록시 사용이 구성된 클라이언트는 이 요청을 위해 대체 서비스에 직접 연결해서는 안 되며, 대신 해당 프록시를 통해 라우팅해야 합니다.

클라이언트가 요청에 대체 서비스를 사용할 때 Alt-Used 헤더 필드(섹션 5)를 사용하여 서버에 이를 알릴 수 있습니다.

클라이언트는 기존 연결에서 요청을 차단할 필요가 없으며, 새로운 대체 연결이 설정될 때까지 기존 연결을 계속 사용할 수 있습니다. 그러나 기존 연결의 보안 속성이 약한 경우(예: 평문 HTTP/1.1) 정보 유출을 피하기 위해 새 연결이 완전히 사용 가능해질 때까지 차단하는 것이 타당할 수 있습니다.

또한 대체 서비스로의 연결이 실패하거나 응답하지 않을 경우, 클라이언트는 오리진이나 다른 대체 서비스로 폴백할 MAY 있습니다. 그러나 이는 다운그레이드 공격의 기초가 될 수 있으므로 대체 서비스의 향상된 보안 속성이 상실될 수 있습니다. 대체 서비스 연결이 기대한 프로토콜을 협상하지 못하면(예: ALPN이 h2를 협상하지 못하거나 h2c로의 Upgrade 요청이 수락되지 않음), 해당 연결은 실패한 것으로 MUST 간주되어야 합니다.

Alt-Svc를 사용하여 대체 서비스가 광고되면, 해당 대체 서비스는 메시지 생성 시점부터 24시간 동안 신선한 것으로 간주됩니다. 이는 "ma" (max-age) 매개변수로 수정될 수 있습니다.

구문:

ma = delta-seconds; see [RFC7234], Section 1.2.1

delta-seconds 값은 응답이 생성된 이후 대체 서비스가 신선하다고 간주되는 초 단위의 수를 나타냅니다.

응답 연령 결정에 대한 세부사항은 [RFC7234]의 섹션 4.2.3을 참조하십시오.

예를 들어, 다음과 같은 응답:

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=600
Age: 30
Alt-Svc: h2=":8000"; ma=60

은 대체 서비스가 다음 60초 동안 사용 가능함을 나타냅니다. 그러나 응답은 이미 30초 동안 캐시되었으므로( Age 헤더 필드 값에 따라) 대체 서비스는 수신 시점부터 추정 전송 시간을 뺀 나머지 30초 동안만 신선합니다.

HTTP 캐싱의 신선도 수명(여기서는 600초)은 Alt-Svc 값의 캐싱에는 영향을 주지 않습니다.

오리진으로부터 Alt-Svc 응답 헤더 필드를 수신하면, 그 값은 해당 오리진에 대한 모든 캐시된 대체 서비스를 무효화하고 대체합니다.

기본적으로 클라이언트는 네트워크 변경을 감지하면 캐시된 대체 서비스를 제거합니다. 클라이언트 접근 네트워크에 특화되지 않은 장기적 대체 서비스를 의도하는 경우, 해당 서비스는 persist 매개변수를 값 "1"로 포함하여 네트워크 구성 변경 이후에도 잠재적으로 유용하다는 힌트를 제공할 수 있습니다.

구문:

persist = "1"

이 명세는 "persist"에 대해 단일 값만 정의합니다. 클라이언트는 "1" 이외의 값을 가진 "persist" 매개변수를 무시해야 합니다.

대체 서비스 캐싱에 대한 일반 요구사항은 섹션 2.2를 참조하십시오.

HTTP 헤더 필드는 IANA가 관리하는 "Message Headers" 레지스트리에 등록됩니다(참조: https://www.iana.org/assignments/message-headers/).

Change controller는 "IETF (iesg@ietf.org) -- Internet Engineering Task Force"입니다.

이 문서는 ALTSVC 프레임 타입을 "HTTP/2 Frame Type" 레지스트리에 등록합니다.

• Frame Type: ALTSVC
• Code: 0xa
• Specification: 섹션 4 of this document

"Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry"는 매개변수 네임스페이스를 정의합니다. 이 레지스트리는 http://www.iana.org/assignments/http-alt-svc-parameters에서 유지됩니다.

대체 서비스를 사용하는 것은 최소한 오리진의 리소스에 대체 포트로 접근하는 것을 의미합니다. 따라서 대체 서비스를 주입하고 광고된 포트에서 수신 대기할 수 있는 공격자는 오리진을 하이재킹할 수 있습니다. 일부 서버에서는 사용자가 공유 포트에서 개인 페이지를 제어하고 덜 권한 있는 포트에서 요청을 수락할 수 있는 것이 일반적입니다.

예를 들어, 공격자가 일부 페이지에 HTTP 응답 헤더 필드를 추가할 수 있다면 Alt-Svc 헤더 필드를 사용해 동일 호스트의 다른 포트로 전체 오리진의 트래픽을 리디렉션할 수 있고, 그 포트가 공격자의 통제 하에 있다면 공격자는 HTTP 서버를 가장할 수 있습니다.

이 위험은 섹션 2.1의 요구사항을 통해 완화됩니다.

서버 측에서는 대체 서비스를 광고할 수 있는 능력을 제한하고 해당 호스트에서 수신 대기 포트를 열 수 있는 사용자를 제한함으로써 이 위험을 줄일 수 있습니다.

대체 서비스 사용으로 호스트가 변경되면 공격자가 오리진에 대한 통신을 하이재킹할 기회가 생길 수 있습니다.

예를 들어, 공격자가 사용자 에이전트를 설득해 "innocent.example.org"의 모든 트래픽을 "evil.example.com"으로 보내게 하면, 공격자는 그 오리진을 사칭할 수 있습니다. 이는 로컬(섹션 9.1의 완화책 참조) 또는 중간자(man-in-the-middle)와 같은 원격 공격을 통해 수행될 수 있습니다.

이것이 섹션 2.1에서 대체 서비스가 오리진 전체를 관할하고 유효하다는 합리적 확신을 클라이언트가 갖도록 요구하는 이유입니다. 예를 들어 오리진에 대한 인증서를 제시하는 것은 대체 서비스가 오리진의 트래픽을 제공할 권한이 있음을 증명합니다.

그러나 이러한 확신은 대체 서비스를 인증하는 데 사용된 방법만큼 강력합니다. 특히 TLS 인증이 사용되는 경우, 공격자의 인증서를 합법적으로 보이게 만드는 잘 알려진 익스플로잇이 존재할 수 있습니다.

대체 서비스는 이런 공격을 지속시키는 데 사용될 수 있습니다. 예를 들어, 중간자는 대상에 대한 TLS 보호 통신을 중간에서 가로채고 큰 신선도 수명을 가진 대체 서비스를 지정하여 사용자 에이전트가 중간자를 사용하지 않을 때에도 계속 공격자에게 트래픽을 전송하도록 할 수 있습니다.

구현은 대체 서비스에 대해서도 인증서 고정(certificate-pinning) 검증(예: [RFC7469])을 직접 연결에서 수행하는 것과 동일하게 수행해야 합니다. 구현은 또한 대체 서비스에 대해 허용되는 인증서에 대한 추가 요구사항을 선택적으로 적용할 수 있습니다.

대체 서비스 사용으로 ALPN 프로토콜이 변경되면, 오리진에 대한 새 연결의 보안 속성이 "일반" 연결과 달라질 수 있습니다. 이는 프로토콜 식별자 자체가 이러한 차이를 암시하기 때문입니다.

예를 들어, "https://" URI에 대해 암호화되지 않은 형태의 엔드투엔드 보안(대부분 TLS를 사용)이 없는 프로토콜이 광고된다면, 이는 URI 스킴이 암시하는 보안 기대를 위반합니다. 따라서 클라이언트는 대체 서비스를 무작정 사용할 수 없으며, 제시된 옵션들이 요구되는 보안 요구사항과 기대를 충족하는지 평가해야 합니다.

대체 서비스를 선택하면 서버가 제공한 새로운 호스트 이름에 연결하게 됩니다. 서버는 고유한 이름을 사용함으로써 클라이언트 요청을 추적할 수 있습니다. "persist" 플래그가 사용될 경우 이러한 추적은 여러 네트워크에 걸쳐 사용자를 추적할 수 있습니다.

요청의 상관 관계를 방지하려는 클라이언트는 상호 연관될 수 있는 여러 요청에 대해 대체 서비스를 사용하지 않기로 결정할 수 있습니다.

사용자 에이전트에서는 오리진별 데이터가 삭제될 때(일반적으로 쿠키가 삭제될 때) 해당 오리진의 모든 대체 서비스 정보가 제거되어야 합니다.

일부 서버측 HTTP 애플리케이션은 연결 컨텍스트에 기반하여 보안을 가정합니다; 예를 들어 포트 443에서 서빙되는 것을 "https://" URI 사용과 동일시하고 그와 관련된 보안 속성을 전제로 하는 경우가 있습니다.

이는 연결 자체의 보안 속성뿐만 아니라 연결 반대편 클라이언트의 상태에도 영향을 미칩니다. 예를 들어 웹 브라우저는 많은 면에서 "https://" URI를 "http://" URI와 다르게 취급합니다.

대체 서비스의 용도 중 하나가 연결을 다른 프로토콜 및 포트로 마이그레이션하는 것이므로, 이러한 애플리케이션들은 특정 연결의 보안 속성에 대해 혼동을 일으킬 수 있으며, 보안 컨텍스트를 전제로 하는 정보(예: 쿠키 및 콘텐츠)를 보안 컨텍스트로 처리하지 않는 클라이언트에 전송할 수 있습니다.

이 위험은 서버에서 프로토콜이 명시적으로 운반하는 URI 스킴(예: HTTP/2의 ":scheme" 또는 HTTP/1.1의 요청 대상의 절대 형식)을 보안 컨텍스트의 표시로 사용함으로써 완화할 수 있습니다.

프로토콜이 스킴을 명시적으로 포함하지 않는 경우(일반적으로 TLS를 사용하는 HTTP/1.1의 경우), 서버는 모든 요청을 비보안 컨텍스트로 가정하거나 비보안 스킴(예: HTTP)에 대해 대체 서비스를 광고하지 않음으로써 이 위험을 완화할 수 있습니다.

10.1. 규범 참조

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

[RFC2818]

Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.

[RFC5226]

Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.

[RFC5234]

Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.

[RFC5890]

Klensin, J., “Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework”, RFC 5890, DOI 10.17487/RFC5890, August 2010.

[RFC6066]

Eastlake, D., “Transport Layer Security (TLS) Extensions: Extension Definitions”, RFC 6066, DOI 10.17487/RFC6066, January 2011.

[RFC6454]

Barth, A., “The Web Origin Concept”, RFC 6454, DOI 10.17487/RFC6454, December 2011.

[RFC7230]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014.

[RFC7234]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014.

[RFC7301]

Friedl, S., Popov, A., Langley, A., and S. Emile, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014.

[RFC7405]

Kyzivat, P., “Case-Sensitive String Support in ABNF”, RFC 7405, DOI 10.17487/RFC7405, December 2014.

[RFC7540]

Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol version 2”, RFC 7540, DOI 10.17487/RFC7540, May 2015.

10.2. 정보 참조

[BCP90]

Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.

[RFC5246]

Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008.

[RFC6265]

Barth, A., “HTTP State Management Mechanism”, RFC 6265, DOI 10.17487/RFC6265, April 2011.

[RFC7469]

Evans, C., Palmer, C., and R. Sleevi, “Public Key Pinning Extension for HTTP”, RFC 7469, DOI 10.17487/RFC7469, April 2015.